# HG changeset patch # User Igor TAmara # Date 1224318464 18000 # Node ID 3502b859cfe470f49524a627874fa439f010bd80 # Parent 8bedea2b8d60df36e6994c03f804760b5293bc7e Minor advance on branches chapter diff -r 8bedea2b8d60 -r 3502b859cfe4 es/Leame.1st --- a/es/Leame.1st Fri Oct 17 13:58:54 2008 -0500 +++ b/es/Leame.1st Sat Oct 18 03:27:44 2008 -0500 @@ -27,7 +27,10 @@ Branch: Rama Bug: Fallo + Changeset: Conjunto de Cambios Command: Orden + Commit: Consignar + Merge: Fusión Milestone: Etapa Release: Versión o liberación de versión diff -r 8bedea2b8d60 -r 3502b859cfe4 es/branch.tex --- a/es/branch.tex Fri Oct 17 13:58:54 2008 -0500 +++ b/es/branch.tex Sat Oct 18 03:27:44 2008 -0500 @@ -88,130 +88,136 @@ llevar cuenta de la posibilidad de generación de binarios. -If you want to remove a tag that you no longer want, use +Si desea eliminar un tag que no desea, use \hgcmdargs{tag}{--remove}. \interaction{tag.remove} -You can also modify a tag at any time, so that it identifies a -different revision, by simply issuing a new \hgcmd{tag} command. -You'll have to use the \hgopt{tag}{-f} option to tell Mercurial that -you \emph{really} want to update the tag. +También puede modificar un tag en cualquier momento para que +identifique una revisión distinta, basta con aplicar una nueva orden +\hgcmd{tag}. Deberá usar la opción \hgopt{tag}{-f} para indicarle a +Mercurial que desea actualizar el tag \emph{en serio}. \interaction{tag.replace} -There will still be a permanent record of the previous identity of the -tag, but Mercurial will no longer use it. There's thus no penalty to -tagging the wrong revision; all you have to do is turn around and tag -the correct revision once you discover your error. +De todas maneras habrá un registro permanente de la antigua identidad +del tag, pero Mercurial no la usará. Por lo tanto no hay castigo al +marcar con un tag una revisión incorrecta; lo único que debe hacer es +mover el tag hacia la revisión correcta tan pronto como localice el +error. -Mercurial stores tags in a normal revision-controlled file in your -repository. If you've created any tags, you'll find them in a file -named \sfilename{.hgtags}. When you run the \hgcmd{tag} command, -Mercurial modifies this file, then automatically commits the change to -it. This means that every time you run \hgcmd{tag}, you'll see a -corresponding changeset in the output of \hgcmd{log}. +Mercurial almacena los tags en un archivo controlado por revisiones en +su repositorio. Si ha creado tags, los encontrará en un archivo +llamado \sfilename{.hgtags}. Cuando invoca la orden \hgcmd{tag}, +Mercurial modifica este archivo, y automáticamente hace commit del +cambio al mismo. Esto significa que cada vez que ejecuta \hgcmd{tag}, +verá el conjunto de cambios correspondiente en la salida de \hgcmd{log}. \interaction{tag.tip} -\subsection{Handling tag conflicts during a merge} +\subsection{Manejo de conflictos entre tags durante una fusión} -You won't often need to care about the \sfilename{.hgtags} file, but -it sometimes makes its presence known during a merge. The format of -the file is simple: it consists of a series of lines. Each line -starts with a changeset hash, followed by a space, followed by the -name of a tag. +Es usual no tener que preocuparse por el archivo \sfilename{.hgtags}, +pero aveces hace su aparición durante una fusión. El formato del +archivo es sencillo: Consiste de una serie de líneas. Cada línea +comienza con un hash de Conjunto de Cambios, seguido por un espacio, +seguido por el nombre de un tag. -If you're resolving a conflict in the \sfilename{.hgtags} file during -a merge, there's one twist to modifying the \sfilename{.hgtags} file: -when Mercurial is parsing the tags in a repository, it \emph{never} -reads the working copy of the \sfilename{.hgtags} file. Instead, it -reads the \emph{most recently committed} revision of the file. +Si está resolviendo un conflicto en el archivo \sfilename{.hgtags} +durante una fusión, hay un detalle para tener en cuenta al modificar +el archivo \sfilename{.hgtags}: +cuando Mercurial parsea los tags en el repositorio \emph{nunca} +lee la copia de trabajo del archivo \sfilename{.hgtags}. En cambio, +lee la versión \emph{consignada más reciente} del archivo. -An unfortunate consequence of this design is that you can't actually -verify that your merged \sfilename{.hgtags} file is correct until -\emph{after} you've committed a change. So if you find yourself -resolving a conflict on \sfilename{.hgtags} during a merge, be sure to -run \hgcmd{tags} after you commit. If it finds an error in the -\sfilename{.hgtags} file, it will report the location of the error, -which you can then fix and commit. You should then run \hgcmd{tags} -again, just to be sure that your fix is correct. - -\subsection{Tags and cloning} +Una consecuencia desafortunada de este diseño es que usted no puede +verificar que su archivo \sfilename{.hgtags} fusionado es correcto hasta +\emph{después} de haber consignado(hecho commit). Así que si se +encuentra resolviendo un conflicto en \sfilename{.hgtags} durante una +fusión, asegúrese de ejecutar la orden \hgcmd{tags} después de +consignar. Si encuentra un error en el archivo \sfilename{.hgtags}, +reportará el lugar del error, que podrá arreglar y después +consignar. Posteriormente ejecute de nuevo la orden \hgcmd{tags} para +asegurar que su arreglo fue correctamente aplicado. -You may have noticed that the \hgcmd{clone} command has a -\hgopt{clone}{-r} option that lets you clone an exact copy of the -repository as of a particular changeset. The new clone will not -contain any project history that comes after the revision you -specified. This has an interaction with tags that can surprise the -unwary. +\subsection{Tags y clonado} -Recall that a tag is stored as a revision to the \sfilename{.hgtags} -file, so that when you create a tag, the changeset in which it's -recorded necessarily refers to an older changeset. When you run -\hgcmdargs{clone}{-r foo} to clone a repository as of tag -\texttt{foo}, the new clone \emph{will not contain the history that - created the tag} that you used to clone the repository. The result -is that you'll get exactly the right subset of the project's history -in the new repository, but \emph{not} the tag you might have expected. +Puede haber notado que la orden \hgcmd{clone} tiene la opción +\hgopt{clone}{-r} que le permite clonar una copia exacta del +repositorio hasta un conjunto de cambios específico. El nuevo clon no +tendrá historia posterior a la revisión que usted haya +especificado. Esta forma de interactuar puede sorprender a los +desprevenidos. -\subsection{When permanent tags are too much} - -Since Mercurial's tags are revision controlled and carried around with -a project's history, everyone you work with will see the tags you -create. But giving names to revisions has uses beyond simply noting -that revision \texttt{4237e45506ee} is really \texttt{v2.0.2}. If -you're trying to track down a subtle bug, you might want a tag to -remind you of something like ``Anne saw the symptoms with this -revision''. +Recuerde que un tag se almacena como una revisión al archivo +\sfilename{.hgtags}, consecuente con esto, cuando crea un tag, el +conjunto de cambios en el cual este se almacena necesariamente se +refiere a un conjunto de cambios anterior. Cuando ejecuta +\hgcmdargs{clone}{-r foo} para clonar un repositorio hasta el tag +\texttt{foo}, el nuevo clon \emph{no contendrá la historia que creo +el tag} que usó para clonar el repositorio. El resultado es que tendrá +exactamente el subconjunto correcto de la historia del proyecto en el +nuevo repositorio, pero, \emph{no} el tag que podría haber esperado. -For cases like this, what you might want to use are \emph{local} tags. -You can create a local tag with the \hgopt{tag}{-l} option to the -\hgcmd{tag} command. This will store the tag in a file called -\sfilename{.hg/localtags}. Unlike \sfilename{.hgtags}, -\sfilename{.hg/localtags} is not revision controlled. Any tags you -create using \hgopt{tag}{-l} remain strictly local to the repository -you're currently working in. +\subsection{Cuando los tags permanentes son demasiado} -\section{The flow of changes---big picture vs. little} +Dado que los tags de Mercurial están controlados por revisiones y se +llevan en la historia del proyecto, todas las personas involucradas +verán los tags que usted haya creado. El hecho de dar nombres a las +revisiones tiene usos más allá que simplemente hacer notar que la +revisión \texttt{4237e45506ee} es realmente \texttt{v2.0.2}. Si está +tratando de encontrar un bug sutil, posiblemente desearía colocar un +tag recordándole algo como ``Ana vió los síntomas con esta revisión''. -To return to the outline I sketched at the beginning of a chapter, -let's think about a project that has multiple concurrent pieces of -work under development at once. +Para estos casos, lo que posiblemente desearía serían tags +\emph{locales}. Puede crear un tag local con la opción \hgopt{tag}{-l} +de la orden \hgcmd{tag}. Esto guardará el tag en un archivo llamado +\sfilename{.hg/localtags}. A diferencia de \sfilename{.hgtags}, +\sfilename{.hg/localtags} no está controlado por revisiones. +Cualquier tag que usted cree usando \hgopt{tag}{-l} se mantendrá +localmente en el repositorio en el que esté trabajando en ese momento. -There might be a push for a new ``main'' release; a new minor bugfix -release to the last main release; and an unexpected ``hot fix'' to an -old release that is now in maintenance mode. +\section{El flujo de cambios---El gran cuadro vs. el pequeño} + +Retomando lo mencionado en el comienzo de un capítulo, pensemos en el +hecho de que un proyecto tiene muchas piezas concurrentes de trabajo +en desarrollo al mismo tiempo. -The usual way people refer to these different concurrent directions of -development is as ``branches''. However, we've already seen numerous -times that Mercurial treats \emph{all of history} as a series of -branches and merges. Really, what we have here is two ideas that are -peripherally related, but which happen to share a name. +Puede haber prisa por una nueva versión ``principal''; Un nueva +versión con un rreglo de fallo a la última versión; y una versión de +``mantenimiento correctivo'' a una versión antigua que ha entrado en +modo de mantenimiento. + +Usualmente la gente se refiere a esas direcciones +concurrentes de desarrollo es como ``ramas''. Aunque hemos visto que +en variadas ocasiones Mercurial trata a \emph{toda la historia} como +una serie de ramas y fusiones. Realmente lo que tenemos aquí es dos +ideas que se relacionan periféricamente, pero que en esencia comparten +un nombre. \begin{itemize} -\item ``Big picture'' branches represent the sweep of a project's - evolution; people give them names, and talk about them in - conversation. -\item ``Little picture'' branches are artefacts of the day-to-day - activity of developing and merging changes. They expose the - narrative of how the code was developed. +\item ``El gran cuadro'' Las ramas representan un barrido de la + evolución del proyecto; la gente les da nombres y hablan acerca de + ellas en sus conversaciones. +\item ``El cuadro pequeño'' Las ramas son artefactos de las + actividades diarias de al desarrollar y fusionar cambios. Exponen la + narrativa de cómo se desarrolló el código. \end{itemize} -\section{Managing big-picture branches in repositories} +\section{Administrar ramas en el gran cuadro en los repositorios} The easiest way to isolate a ``big picture'' branch in Mercurial is in -a dedicated repository. If you have an existing shared -repository---let's call it \texttt{myproject}---that reaches a ``1.0'' +a dedicated repositorio. If you have an existing shared +repositorio---let's call it \texttt{myproject}---that reaches a ``1.0'' milestone, you can start to prepare for future maintenance releases on top of version~1.0 by tagging the revision from which you prepared the~1.0 release. \interaction{branch-repo.tag} -You can then clone a new shared \texttt{myproject-1.0.1} repository as +You can then clone a new shared \texttt{myproject-1.0.1} repositorio as of that tag. \interaction{branch-repo.clone} Afterwards, if someone needs to work on a bug fix that ought to go into an upcoming~1.0.1 minor release, they clone the -\texttt{myproject-1.0.1} repository, make their changes, and push them +\texttt{myproject-1.0.1} repositorio, make their changes, and push them back. \interaction{branch-repo.bugfix} Meanwhile, development for the next major release can continue, -isolated and unabated, in the \texttt{myproject} repository. +isolated and unabated, in the \texttt{myproject} repositorio. \interaction{branch-repo.new} \section{Don't repeat yourself: merging across branches} @@ -230,21 +236,21 @@ to the main branch. \interaction{branch-repo.merge} -\section{Naming branches within one repository} +\section{Naming branches within one repositorio} -In most instances, isolating branches in repositories is the right +In most instances, isolating branches in repositorios is the right approach. Its simplicity makes it easy to understand; and so it's hard to make mistakes. There's a one-to-one relationship between branches you're working in and directories on your system. This lets you use normal (non-Mercurial-aware) tools to work on files within a -branch/repository. +branch/repositorio. If you're more in the ``power user'' category (\emph{and} your collaborators are too), there is an alternative way of handling branches that you can consider. I've already mentioned the human-level distinction between ``small picture'' and ``big picture'' branches. While Mercurial works with multiple ``small picture'' -branches in a repository all the time (for example after you pull +branches in a repositorio all the time (for example after you pull changes in, but before you merge them), it can \emph{also} work with multiple ``big picture'' branches. @@ -262,7 +268,7 @@ To start working with named branches, use the \hgcmd{branches} command. This command lists the named branches already present in -your repository, telling you which changeset is the tip of each. +your repositorio, telling you which changeset is the tip of each. \interaction{branch-named.branches} Since you haven't created any named branches yet, the only one that exists is \texttt{default}. @@ -304,9 +310,9 @@ names tend to have fairly long lifetimes. (This isn't a rule, just an observation.) -\section{Dealing with multiple named branches in a repository} +\section{Dealing with multiple named branches in a repositorio} -If you have more than one named branch in a repository, Mercurial will +If you have more than one named branch in a repositorio, Mercurial will remember the branch that your working directory on when you start a command like \hgcmd{update} or \hgcmdargs{pull}{-u}. It will update the working directory to the tip of this branch, no matter what the @@ -316,7 +322,7 @@ This behaviour is a little subtle, so let's see it in action. First, let's remind ourselves what branch we're currently on, and what -branches are in our repository. +branches are in our repositorio. \interaction{branch-named.parents} We're on the \texttt{bar} branch, but there also exists an older \hgcmd{foo} branch. @@ -339,7 +345,7 @@ \section{Branch names and merging} As you've probably noticed, merges in Mercurial are not symmetrical. -Let's say our repository has two heads, 17 and 23. If I +Let's say our repositorio has two heads, 17 and 23. If I \hgcmd{update} to 17 and then \hgcmd{merge} with 23, Mercurial records 17 as the first parent of the merge, and 23 as the second. Whereas if I \hgcmd{update} to 23 and then \hgcmd{merge} with 17, it records 23 @@ -351,7 +357,7 @@ branch name is \texttt{foo}, and you merge with \texttt{bar}, the branch name will still be \texttt{foo} after you merge. -It's not unusual for a repository to contain multiple heads, each with +It's not unusual for a repositorio to contain multiple heads, each with the same branch name. Let's say I'm working on the \texttt{foo} branch, and so are you. We commit different changes; I pull your changes; I now have two heads, each claiming to be on the \texttt{foo} @@ -373,7 +379,7 @@ You shouldn't think of named branches as applicable only to situations where you have multiple long-lived branches cohabiting in a single -repository. They're very useful even in the one-branch-per-repository +repositorio. They're very useful even in the one-branch-per-repositorio case. In the simplest case, giving a name to each branch gives you a @@ -381,7 +387,7 @@ gives you more context when you're trying to follow the history of a long-lived branchy project. -If you're working with shared repositories, you can set up a +If you're working with shared repositorios, you can set up a \hook{pretxnchangegroup} hook on each that will block incoming changes that have the ``wrong'' branch name. This provides a simple, but effective, defence against people accidentally pushing changes from a