hgbook
changeset 422:59fbfb7e790c
translated some more comments
author | Javier Rojas <jerojasro@devnull.li> |
---|---|
date | Mon Nov 17 20:04:37 2008 -0500 (2008-11-17) |
parents | 93bd78a98b78 |
children | f907df38efef |
files | es/concepts.tex |
line diff
1.1 --- a/es/concepts.tex Sat Nov 15 20:08:40 2008 -0500 1.2 +++ b/es/concepts.tex Mon Nov 17 20:04:37 2008 -0500 1.3 @@ -339,99 +339,109 @@ 1.4 hace la consignación; sólo modifica el estado de directorio para 1.5 anotar sus nuevos padres. 1.6 1.7 -\subsection{Creating a new head} 1.8 - 1.9 -It's perfectly normal to update the working directory to a changeset 1.10 -other than the current tip. For example, you might want to know what 1.11 -your project looked like last Tuesday, or you could be looking through 1.12 -changesets to see which one introduced a bug. In cases like this, the 1.13 -natural thing to do is update the working directory to the changeset 1.14 -you're interested in, and then examine the files in the working 1.15 -directory directly to see their contents as they werea when you 1.16 -committed that changeset. The effect of this is shown in 1.17 -figure~\ref{fig:concepts:wdir-pre-branch}. 1.18 +\subsection{Creación de un nuevo frente} 1.19 + 1.20 +Es perfectamente normal actualizar el directorio de trabajo a un 1.21 +conjunto de cambios diferente a la punta actual. Por ejemplo, usted 1.22 +podría desear saber en qué estado se encontraba su proyecto el martes 1.23 +pasado, o podría estar buscando en todos los conjuntos de cambios para 1.24 +saber cuándo se introdujo un fallo. En casos como éstos, la acción 1.25 +natural es actualizar el directorio de trabajo al conjunto de cambios 1.26 +de su interés, y examinar directamente los ficheros en el directorio 1.27 +de trabajo para ver sus contenidos tal como estaban en el momento de 1.28 +hacer la consignación. El efecto que tiene esto se muestra en la 1.29 +figura~\ref{fig:concepts:wdir-pre-branch}. 1.30 1.31 \begin{figure}[ht] 1.32 \centering 1.33 \grafix{wdir-pre-branch} 1.34 - \caption{The working directory, updated to an older changeset} 1.35 + \caption{El directorio de trabajo, actualizado a un conjunto de 1.36 + cambios anterior} 1.37 \label{fig:concepts:wdir-pre-branch} 1.38 \end{figure} 1.39 1.40 -Having updated the working directory to an older changeset, what 1.41 -happens if you make some changes, and then commit? Mercurial behaves 1.42 -in the same way as I outlined above. The parents of the working 1.43 -directory become the parents of the new changeset. This new changeset 1.44 -has no children, so it becomes the new tip. And the repository now 1.45 -contains two changesets that have no children; we call these 1.46 -\emph{heads}. You can see the structure that this creates in 1.47 -figure~\ref{fig:concepts:wdir-branch}. 1.48 +Una vez se ha actualizado el directorio de trabajo a un conjunto de 1.49 +cambios anterior, qué pasa si se hacen cambios, y luego se hace una 1.50 +consignación? Mercurial se comporta en la misma forma que describí 1.51 +anteriormente. Los padres del directorio de trabajo se convierten en 1.52 +los padres del nuevo conjunto de cambios. Este nuevo conjunto de 1.53 +cambios no tiene hijos, así que se convierte en la nueva punta. Y el 1.54 +repositorio tiene ahora dos conjuntos de cambios que no tienen hijos; 1.55 +a éstos los llamamos \emph{frentes}. Usted puede apreciar la 1.56 +estructura que esto crea en la figura~\ref{fig:concepts:wdir-branch}. 1.57 1.58 \begin{figure}[ht] 1.59 \centering 1.60 \grafix{wdir-branch} 1.61 - \caption{After a commit made while synced to an older changeset} 1.62 + \caption{Después de una consignación hecha mientras se usaba un 1.63 + conjunto de cambios anterior} 1.64 \label{fig:concepts:wdir-branch} 1.65 \end{figure} 1.66 1.67 \begin{note} 1.68 - If you're new to Mercurial, you should keep in mind a common 1.69 - ``error'', which is to use the \hgcmd{pull} command without any 1.70 - options. By default, the \hgcmd{pull} command \emph{does not} 1.71 - update the working directory, so you'll bring new changesets into 1.72 - your repository, but the working directory will stay synced at the 1.73 - same changeset as before the pull. If you make some changes and 1.74 - commit afterwards, you'll thus create a new head, because your 1.75 - working directory isn't synced to whatever the current tip is. 1.76 - 1.77 - I put the word ``error'' in quotes because all that you need to do 1.78 - to rectify this situation is \hgcmd{merge}, then \hgcmd{commit}. In 1.79 - other words, this almost never has negative consequences; it just 1.80 - surprises people. I'll discuss other ways to avoid this behaviour, 1.81 - and why Mercurial behaves in this initially surprising way, later 1.82 - on. 1.83 + Si usted es nuevo en Mercurial, debería tener en mente un 1.84 + ``error'' común, que es usar el comando \hgcmd{pull} sin ninguna 1.85 + opción. Por defecto, el comando \hgcmd{pull} \emph{no} actualiza 1.86 + el directorio de trabajo, así que usted termina trayendo nuevos 1.87 + conjuntos de cambios a su repositorio, pero el directorio de 1.88 + trabajo sigue usando el mismo conjunto de cambios que tenía antes 1.89 + de jalar. Si usted hace algunos cambios, y luego hace una 1.90 + consignación, estará creando un nuevo frente, porque su directorio 1.91 + de trabajo no es sincronizado a cualquiera que sea la nueva punta. 1.92 + 1.93 + Pongo la palabra ``error'' en comillas porque todo lo que usted 1.94 + debe hacer para rectificar la situación es hacer una fusión 1.95 + (\hgcmd{merge}), y luego una consignación (\hgcmd{commit}). En 1.96 + otras palabras, esto casi nunca tiene consecuencias negativas; 1.97 + sólo sorprende a la gente. Discutiré otras formas de evitar este 1.98 + comportamiento, y porqué Mercurial se comporta de esta forma, 1.99 + inicialmente sorprendente, más adelante. 1.100 \end{note} 1.101 1.102 -\subsection{Merging heads} 1.103 - 1.104 -When you run the \hgcmd{merge} command, Mercurial leaves the first 1.105 -parent of the working directory unchanged, and sets the second parent 1.106 -to the changeset you're merging with, as shown in 1.107 -figure~\ref{fig:concepts:wdir-merge}. 1.108 +\subsection{Fusión de frentes} 1.109 + 1.110 +Cuando usted ejecuta el comando \hgcmd{merge}, Mercurial deja el 1.111 +primer padre del directorio de trabajo intacto, y escribe como segundo 1.112 +padre el conjunto de cambios contra el cual usted está haciendo la 1.113 +fusión, como se muestra en la figura~\ref{fig:concepts:wdir-merge}. 1.114 1.115 \begin{figure}[ht] 1.116 \centering 1.117 \grafix{wdir-merge} 1.118 - \caption{Merging two heads} 1.119 + \caption{Fusión de dos frentes} 1.120 \label{fig:concepts:wdir-merge} 1.121 \end{figure} 1.122 1.123 -Mercurial also has to modify the working directory, to merge the files 1.124 -managed in the two changesets. Simplified a little, the merging 1.125 -process goes like this, for every file in the manifests of both 1.126 -changesets. 1.127 +Mercurial también debe modificar el directorio de trabajo, para 1.128 +fusionar los ficheros que él monitorea en los dos conjuntos de 1.129 +cambios. Con algunas simplificaciones, el proceso es el siguiente, por 1.130 +cada fichero en los manifiestos de ambos conjuntos de cambios. 1.131 \begin{itemize} 1.132 -\item If neither changeset has modified a file, do nothing with that 1.133 - file. 1.134 -\item If one changeset has modified a file, and the other hasn't, 1.135 - create the modified copy of the file in the working directory. 1.136 -\item If one changeset has removed a file, and the other hasn't (or 1.137 - has also deleted it), delete the file from the working directory. 1.138 -\item If one changeset has removed a file, but the other has modified 1.139 - the file, ask the user what to do: keep the modified file, or remove 1.140 - it? 1.141 -\item If both changesets have modified a file, invoke an external 1.142 - merge program to choose the new contents for the merged file. This 1.143 - may require input from the user. 1.144 -\item If one changeset has modified a file, and the other has renamed 1.145 - or copied the file, make sure that the changes follow the new name 1.146 - of the file. 1.147 +\item Si ningún conjunto de cambios ha modificado un fichero, no se 1.148 + hace nada con el mismo. 1.149 +\item Si un conjunto de cambios ha modificado un fichero, y el otro no 1.150 + lo ha hecho, se crea una copia del fichero con las modificaciones 1.151 + pertinentes en el directorio de trabajo. 1.152 +\item Si un conjunto de cambios borra un fichero, y el otro no lo ha 1.153 + hecho (o también lo borró), se borra dicho fichero del directorio 1.154 + de trabajo. 1.155 +\item Si un conjunto de cambios ha borrado un fichero, pero el otro lo ha 1.156 + modificado, se le pregunta al usuario qué hacer: conservar el 1.157 + fichero modificado, o borrarlo? 1.158 +\item Si ambos conjuntos de cambios han modificado un fichero, se 1.159 + invoca el programa externo de fusión para definir el nuevo 1.160 + contenido del fichero fusionado. Esto puede requerir interacción 1.161 + directa de parte del usuario. 1.162 +\item Si un conjunto de cambios ha modificado un fichero, y el otro ha 1.163 + renombrado o copiado el mismo, asegurarse de que los cambios sigan 1.164 + al nuevo nombre de fichero. 1.165 \end{itemize} 1.166 -There are more details---merging has plenty of corner cases---but 1.167 -these are the most common choices that are involved in a merge. As 1.168 -you can see, most cases are completely automatic, and indeed most 1.169 -merges finish automatically, without requiring your input to resolve 1.170 -any conflicts. 1.171 +Hay más detalles---hacer una fusión tiene una gran cantidad de casos 1.172 +especiales---pero éstas son las elecciones más comunes que se ven 1.173 +involucradas en una fusión. Como usted puede ver, muchos de los casos 1.174 +son completamente automáticos, y de hecho la mayoría de las fusiones 1.175 +terminan automáticamente, sin requerir la interacción del usuario para 1.176 +resolver ningún conflicto. 1.177 1.178 When you're thinking about what happens when you commit after a merge, 1.179 once again the working directory is ``the changeset I'm about to