hgbook
changeset 331:3502b859cfe4
Minor advance on branches chapter
author | Igor TAmara <igor@tamarapatino.org> |
---|---|
date | Sat Oct 18 03:27:44 2008 -0500 (2008-10-18) |
parents | 8bedea2b8d60 |
children | d13a05515acf |
files | es/Leame.1st es/branch.tex |
line diff
1.1 --- a/es/Leame.1st Fri Oct 17 13:58:54 2008 -0500 1.2 +++ b/es/Leame.1st Sat Oct 18 03:27:44 2008 -0500 1.3 @@ -27,7 +27,10 @@ 1.4 1.5 Branch: Rama 1.6 Bug: Fallo 1.7 + Changeset: Conjunto de Cambios 1.8 Command: Orden 1.9 + Commit: Consignar 1.10 + Merge: Fusión 1.11 Milestone: Etapa 1.12 Release: Versión o liberación de versión 1.13
2.1 --- a/es/branch.tex Fri Oct 17 13:58:54 2008 -0500 2.2 +++ b/es/branch.tex Sat Oct 18 03:27:44 2008 -0500 2.3 @@ -88,130 +88,136 @@ 2.4 llevar cuenta de la posibilidad de generación de binarios. 2.5 2.6 2.7 -If you want to remove a tag that you no longer want, use 2.8 +Si desea eliminar un tag que no desea, use 2.9 \hgcmdargs{tag}{--remove}. 2.10 \interaction{tag.remove} 2.11 -You can also modify a tag at any time, so that it identifies a 2.12 -different revision, by simply issuing a new \hgcmd{tag} command. 2.13 -You'll have to use the \hgopt{tag}{-f} option to tell Mercurial that 2.14 -you \emph{really} want to update the tag. 2.15 +También puede modificar un tag en cualquier momento para que 2.16 +identifique una revisión distinta, basta con aplicar una nueva orden 2.17 +\hgcmd{tag}. Deberá usar la opción \hgopt{tag}{-f} para indicarle a 2.18 +Mercurial que desea actualizar el tag \emph{en serio}. 2.19 \interaction{tag.replace} 2.20 -There will still be a permanent record of the previous identity of the 2.21 -tag, but Mercurial will no longer use it. There's thus no penalty to 2.22 -tagging the wrong revision; all you have to do is turn around and tag 2.23 -the correct revision once you discover your error. 2.24 - 2.25 -Mercurial stores tags in a normal revision-controlled file in your 2.26 -repository. If you've created any tags, you'll find them in a file 2.27 -named \sfilename{.hgtags}. When you run the \hgcmd{tag} command, 2.28 -Mercurial modifies this file, then automatically commits the change to 2.29 -it. This means that every time you run \hgcmd{tag}, you'll see a 2.30 -corresponding changeset in the output of \hgcmd{log}. 2.31 +De todas maneras habrá un registro permanente de la antigua identidad 2.32 +del tag, pero Mercurial no la usará. Por lo tanto no hay castigo al 2.33 +marcar con un tag una revisión incorrecta; lo único que debe hacer es 2.34 +mover el tag hacia la revisión correcta tan pronto como localice el 2.35 +error. 2.36 + 2.37 +Mercurial almacena los tags en un archivo controlado por revisiones en 2.38 +su repositorio. Si ha creado tags, los encontrará en un archivo 2.39 +llamado \sfilename{.hgtags}. Cuando invoca la orden \hgcmd{tag}, 2.40 +Mercurial modifica este archivo, y automáticamente hace commit del 2.41 +cambio al mismo. Esto significa que cada vez que ejecuta \hgcmd{tag}, 2.42 +verá el conjunto de cambios correspondiente en la salida de \hgcmd{log}. 2.43 \interaction{tag.tip} 2.44 2.45 -\subsection{Handling tag conflicts during a merge} 2.46 - 2.47 -You won't often need to care about the \sfilename{.hgtags} file, but 2.48 -it sometimes makes its presence known during a merge. The format of 2.49 -the file is simple: it consists of a series of lines. Each line 2.50 -starts with a changeset hash, followed by a space, followed by the 2.51 -name of a tag. 2.52 - 2.53 -If you're resolving a conflict in the \sfilename{.hgtags} file during 2.54 -a merge, there's one twist to modifying the \sfilename{.hgtags} file: 2.55 -when Mercurial is parsing the tags in a repository, it \emph{never} 2.56 -reads the working copy of the \sfilename{.hgtags} file. Instead, it 2.57 -reads the \emph{most recently committed} revision of the file. 2.58 - 2.59 -An unfortunate consequence of this design is that you can't actually 2.60 -verify that your merged \sfilename{.hgtags} file is correct until 2.61 -\emph{after} you've committed a change. So if you find yourself 2.62 -resolving a conflict on \sfilename{.hgtags} during a merge, be sure to 2.63 -run \hgcmd{tags} after you commit. If it finds an error in the 2.64 -\sfilename{.hgtags} file, it will report the location of the error, 2.65 -which you can then fix and commit. You should then run \hgcmd{tags} 2.66 -again, just to be sure that your fix is correct. 2.67 - 2.68 -\subsection{Tags and cloning} 2.69 - 2.70 -You may have noticed that the \hgcmd{clone} command has a 2.71 -\hgopt{clone}{-r} option that lets you clone an exact copy of the 2.72 -repository as of a particular changeset. The new clone will not 2.73 -contain any project history that comes after the revision you 2.74 -specified. This has an interaction with tags that can surprise the 2.75 -unwary. 2.76 - 2.77 -Recall that a tag is stored as a revision to the \sfilename{.hgtags} 2.78 -file, so that when you create a tag, the changeset in which it's 2.79 -recorded necessarily refers to an older changeset. When you run 2.80 -\hgcmdargs{clone}{-r foo} to clone a repository as of tag 2.81 -\texttt{foo}, the new clone \emph{will not contain the history that 2.82 - created the tag} that you used to clone the repository. The result 2.83 -is that you'll get exactly the right subset of the project's history 2.84 -in the new repository, but \emph{not} the tag you might have expected. 2.85 - 2.86 -\subsection{When permanent tags are too much} 2.87 - 2.88 -Since Mercurial's tags are revision controlled and carried around with 2.89 -a project's history, everyone you work with will see the tags you 2.90 -create. But giving names to revisions has uses beyond simply noting 2.91 -that revision \texttt{4237e45506ee} is really \texttt{v2.0.2}. If 2.92 -you're trying to track down a subtle bug, you might want a tag to 2.93 -remind you of something like ``Anne saw the symptoms with this 2.94 -revision''. 2.95 - 2.96 -For cases like this, what you might want to use are \emph{local} tags. 2.97 -You can create a local tag with the \hgopt{tag}{-l} option to the 2.98 -\hgcmd{tag} command. This will store the tag in a file called 2.99 -\sfilename{.hg/localtags}. Unlike \sfilename{.hgtags}, 2.100 -\sfilename{.hg/localtags} is not revision controlled. Any tags you 2.101 -create using \hgopt{tag}{-l} remain strictly local to the repository 2.102 -you're currently working in. 2.103 - 2.104 -\section{The flow of changes---big picture vs. little} 2.105 - 2.106 -To return to the outline I sketched at the beginning of a chapter, 2.107 -let's think about a project that has multiple concurrent pieces of 2.108 -work under development at once. 2.109 - 2.110 -There might be a push for a new ``main'' release; a new minor bugfix 2.111 -release to the last main release; and an unexpected ``hot fix'' to an 2.112 -old release that is now in maintenance mode. 2.113 - 2.114 -The usual way people refer to these different concurrent directions of 2.115 -development is as ``branches''. However, we've already seen numerous 2.116 -times that Mercurial treats \emph{all of history} as a series of 2.117 -branches and merges. Really, what we have here is two ideas that are 2.118 -peripherally related, but which happen to share a name. 2.119 +\subsection{Manejo de conflictos entre tags durante una fusión} 2.120 + 2.121 +Es usual no tener que preocuparse por el archivo \sfilename{.hgtags}, 2.122 +pero aveces hace su aparición durante una fusión. El formato del 2.123 +archivo es sencillo: Consiste de una serie de líneas. Cada línea 2.124 +comienza con un hash de Conjunto de Cambios, seguido por un espacio, 2.125 +seguido por el nombre de un tag. 2.126 + 2.127 +Si está resolviendo un conflicto en el archivo \sfilename{.hgtags} 2.128 +durante una fusión, hay un detalle para tener en cuenta al modificar 2.129 +el archivo \sfilename{.hgtags}: 2.130 +cuando Mercurial parsea los tags en el repositorio \emph{nunca} 2.131 +lee la copia de trabajo del archivo \sfilename{.hgtags}. En cambio, 2.132 +lee la versión \emph{consignada más reciente} del archivo. 2.133 + 2.134 +Una consecuencia desafortunada de este diseño es que usted no puede 2.135 +verificar que su archivo \sfilename{.hgtags} fusionado es correcto hasta 2.136 +\emph{después} de haber consignado(hecho commit). Así que si se 2.137 +encuentra resolviendo un conflicto en \sfilename{.hgtags} durante una 2.138 +fusión, asegúrese de ejecutar la orden \hgcmd{tags} después de 2.139 +consignar. Si encuentra un error en el archivo \sfilename{.hgtags}, 2.140 +reportará el lugar del error, que podrá arreglar y después 2.141 +consignar. Posteriormente ejecute de nuevo la orden \hgcmd{tags} para 2.142 +asegurar que su arreglo fue correctamente aplicado. 2.143 + 2.144 +\subsection{Tags y clonado} 2.145 + 2.146 +Puede haber notado que la orden \hgcmd{clone} tiene la opción 2.147 +\hgopt{clone}{-r} que le permite clonar una copia exacta del 2.148 +repositorio hasta un conjunto de cambios específico. El nuevo clon no 2.149 +tendrá historia posterior a la revisión que usted haya 2.150 +especificado. Esta forma de interactuar puede sorprender a los 2.151 +desprevenidos. 2.152 + 2.153 +Recuerde que un tag se almacena como una revisión al archivo 2.154 +\sfilename{.hgtags}, consecuente con esto, cuando crea un tag, el 2.155 +conjunto de cambios en el cual este se almacena necesariamente se 2.156 +refiere a un conjunto de cambios anterior. Cuando ejecuta 2.157 +\hgcmdargs{clone}{-r foo} para clonar un repositorio hasta el tag 2.158 +\texttt{foo}, el nuevo clon \emph{no contendrá la historia que creo 2.159 +el tag} que usó para clonar el repositorio. El resultado es que tendrá 2.160 +exactamente el subconjunto correcto de la historia del proyecto en el 2.161 +nuevo repositorio, pero, \emph{no} el tag que podría haber esperado. 2.162 + 2.163 +\subsection{Cuando los tags permanentes son demasiado} 2.164 + 2.165 +Dado que los tags de Mercurial están controlados por revisiones y se 2.166 +llevan en la historia del proyecto, todas las personas involucradas 2.167 +verán los tags que usted haya creado. El hecho de dar nombres a las 2.168 +revisiones tiene usos más allá que simplemente hacer notar que la 2.169 +revisión \texttt{4237e45506ee} es realmente \texttt{v2.0.2}. Si está 2.170 +tratando de encontrar un bug sutil, posiblemente desearía colocar un 2.171 +tag recordándole algo como ``Ana vió los síntomas con esta revisión''. 2.172 + 2.173 +Para estos casos, lo que posiblemente desearía serían tags 2.174 +\emph{locales}. Puede crear un tag local con la opción \hgopt{tag}{-l} 2.175 +de la orden \hgcmd{tag}. Esto guardará el tag en un archivo llamado 2.176 +\sfilename{.hg/localtags}. A diferencia de \sfilename{.hgtags}, 2.177 +\sfilename{.hg/localtags} no está controlado por revisiones. 2.178 +Cualquier tag que usted cree usando \hgopt{tag}{-l} se mantendrá 2.179 +localmente en el repositorio en el que esté trabajando en ese momento. 2.180 + 2.181 +\section{El flujo de cambios---El gran cuadro vs. el pequeño} 2.182 + 2.183 +Retomando lo mencionado en el comienzo de un capítulo, pensemos en el 2.184 +hecho de que un proyecto tiene muchas piezas concurrentes de trabajo 2.185 +en desarrollo al mismo tiempo. 2.186 + 2.187 +Puede haber prisa por una nueva versión ``principal''; Un nueva 2.188 +versión con un rreglo de fallo a la última versión; y una versión de 2.189 +``mantenimiento correctivo'' a una versión antigua que ha entrado en 2.190 +modo de mantenimiento. 2.191 + 2.192 +Usualmente la gente se refiere a esas direcciones 2.193 +concurrentes de desarrollo es como ``ramas''. Aunque hemos visto que 2.194 +en variadas ocasiones Mercurial trata a \emph{toda la historia} como 2.195 +una serie de ramas y fusiones. Realmente lo que tenemos aquí es dos 2.196 +ideas que se relacionan periféricamente, pero que en esencia comparten 2.197 +un nombre. 2.198 \begin{itemize} 2.199 -\item ``Big picture'' branches represent the sweep of a project's 2.200 - evolution; people give them names, and talk about them in 2.201 - conversation. 2.202 -\item ``Little picture'' branches are artefacts of the day-to-day 2.203 - activity of developing and merging changes. They expose the 2.204 - narrative of how the code was developed. 2.205 +\item ``El gran cuadro'' Las ramas representan un barrido de la 2.206 + evolución del proyecto; la gente les da nombres y hablan acerca de 2.207 + ellas en sus conversaciones. 2.208 +\item ``El cuadro pequeño'' Las ramas son artefactos de las 2.209 + actividades diarias de al desarrollar y fusionar cambios. Exponen la 2.210 + narrativa de cómo se desarrolló el código. 2.211 \end{itemize} 2.212 2.213 -\section{Managing big-picture branches in repositories} 2.214 +\section{Administrar ramas en el gran cuadro en los repositorios} 2.215 2.216 The easiest way to isolate a ``big picture'' branch in Mercurial is in 2.217 -a dedicated repository. If you have an existing shared 2.218 -repository---let's call it \texttt{myproject}---that reaches a ``1.0'' 2.219 +a dedicated repositorio. If you have an existing shared 2.220 +repositorio---let's call it \texttt{myproject}---that reaches a ``1.0'' 2.221 milestone, you can start to prepare for future maintenance releases on 2.222 top of version~1.0 by tagging the revision from which you prepared 2.223 the~1.0 release. 2.224 \interaction{branch-repo.tag} 2.225 -You can then clone a new shared \texttt{myproject-1.0.1} repository as 2.226 +You can then clone a new shared \texttt{myproject-1.0.1} repositorio as 2.227 of that tag. 2.228 \interaction{branch-repo.clone} 2.229 2.230 Afterwards, if someone needs to work on a bug fix that ought to go 2.231 into an upcoming~1.0.1 minor release, they clone the 2.232 -\texttt{myproject-1.0.1} repository, make their changes, and push them 2.233 +\texttt{myproject-1.0.1} repositorio, make their changes, and push them 2.234 back. 2.235 \interaction{branch-repo.bugfix} 2.236 Meanwhile, development for the next major release can continue, 2.237 -isolated and unabated, in the \texttt{myproject} repository. 2.238 +isolated and unabated, in the \texttt{myproject} repositorio. 2.239 \interaction{branch-repo.new} 2.240 2.241 \section{Don't repeat yourself: merging across branches} 2.242 @@ -230,21 +236,21 @@ 2.243 to the main branch. 2.244 \interaction{branch-repo.merge} 2.245 2.246 -\section{Naming branches within one repository} 2.247 - 2.248 -In most instances, isolating branches in repositories is the right 2.249 +\section{Naming branches within one repositorio} 2.250 + 2.251 +In most instances, isolating branches in repositorios is the right 2.252 approach. Its simplicity makes it easy to understand; and so it's 2.253 hard to make mistakes. There's a one-to-one relationship between 2.254 branches you're working in and directories on your system. This lets 2.255 you use normal (non-Mercurial-aware) tools to work on files within a 2.256 -branch/repository. 2.257 +branch/repositorio. 2.258 2.259 If you're more in the ``power user'' category (\emph{and} your 2.260 collaborators are too), there is an alternative way of handling 2.261 branches that you can consider. I've already mentioned the 2.262 human-level distinction between ``small picture'' and ``big picture'' 2.263 branches. While Mercurial works with multiple ``small picture'' 2.264 -branches in a repository all the time (for example after you pull 2.265 +branches in a repositorio all the time (for example after you pull 2.266 changes in, but before you merge them), it can \emph{also} work with 2.267 multiple ``big picture'' branches. 2.268 2.269 @@ -262,7 +268,7 @@ 2.270 2.271 To start working with named branches, use the \hgcmd{branches} 2.272 command. This command lists the named branches already present in 2.273 -your repository, telling you which changeset is the tip of each. 2.274 +your repositorio, telling you which changeset is the tip of each. 2.275 \interaction{branch-named.branches} 2.276 Since you haven't created any named branches yet, the only one that 2.277 exists is \texttt{default}. 2.278 @@ -304,9 +310,9 @@ 2.279 names tend to have fairly long lifetimes. (This isn't a rule, just an 2.280 observation.) 2.281 2.282 -\section{Dealing with multiple named branches in a repository} 2.283 - 2.284 -If you have more than one named branch in a repository, Mercurial will 2.285 +\section{Dealing with multiple named branches in a repositorio} 2.286 + 2.287 +If you have more than one named branch in a repositorio, Mercurial will 2.288 remember the branch that your working directory on when you start a 2.289 command like \hgcmd{update} or \hgcmdargs{pull}{-u}. It will update 2.290 the working directory to the tip of this branch, no matter what the 2.291 @@ -316,7 +322,7 @@ 2.292 2.293 This behaviour is a little subtle, so let's see it in action. First, 2.294 let's remind ourselves what branch we're currently on, and what 2.295 -branches are in our repository. 2.296 +branches are in our repositorio. 2.297 \interaction{branch-named.parents} 2.298 We're on the \texttt{bar} branch, but there also exists an older 2.299 \hgcmd{foo} branch. 2.300 @@ -339,7 +345,7 @@ 2.301 \section{Branch names and merging} 2.302 2.303 As you've probably noticed, merges in Mercurial are not symmetrical. 2.304 -Let's say our repository has two heads, 17 and 23. If I 2.305 +Let's say our repositorio has two heads, 17 and 23. If I 2.306 \hgcmd{update} to 17 and then \hgcmd{merge} with 23, Mercurial records 2.307 17 as the first parent of the merge, and 23 as the second. Whereas if 2.308 I \hgcmd{update} to 23 and then \hgcmd{merge} with 17, it records 23 2.309 @@ -351,7 +357,7 @@ 2.310 branch name is \texttt{foo}, and you merge with \texttt{bar}, the 2.311 branch name will still be \texttt{foo} after you merge. 2.312 2.313 -It's not unusual for a repository to contain multiple heads, each with 2.314 +It's not unusual for a repositorio to contain multiple heads, each with 2.315 the same branch name. Let's say I'm working on the \texttt{foo} 2.316 branch, and so are you. We commit different changes; I pull your 2.317 changes; I now have two heads, each claiming to be on the \texttt{foo} 2.318 @@ -373,7 +379,7 @@ 2.319 2.320 You shouldn't think of named branches as applicable only to situations 2.321 where you have multiple long-lived branches cohabiting in a single 2.322 -repository. They're very useful even in the one-branch-per-repository 2.323 +repositorio. They're very useful even in the one-branch-per-repositorio 2.324 case. 2.325 2.326 In the simplest case, giving a name to each branch gives you a 2.327 @@ -381,7 +387,7 @@ 2.328 gives you more context when you're trying to follow the history of a 2.329 long-lived branchy project. 2.330 2.331 -If you're working with shared repositories, you can set up a 2.332 +If you're working with shared repositorios, you can set up a 2.333 \hook{pretxnchangegroup} hook on each that will block incoming changes 2.334 that have the ``wrong'' branch name. This provides a simple, but 2.335 effective, defence against people accidentally pushing changes from a