1.1 --- a/es/branch.tex	Sun Oct 19 04:31:49 2008 -0500
     1.2 +++ b/es/branch.tex	Mon Oct 27 13:44:21 2008 -0500
     1.3 @@ -220,179 +220,183 @@
     1.4  continuar asilada e incólume, en el repositorio \texttt{myproject}.
     1.5  \interaction{branch-repo.new}
     1.6  
     1.7 -\section{Don't repeat yourself: merging across branches}
     1.8 -
     1.9 -In many cases, if you have a bug to fix on a maintenance branch, the
    1.10 -chances are good that the bug exists on your project's main branch
    1.11 -(and possibly other maintenance branches, too).  It's a rare developer
    1.12 -who wants to fix the same bug multiple times, so let's look at a few
    1.13 -ways that Mercurial can help you to manage these bugfixes without
    1.14 -duplicating your work.
    1.15 -
    1.16 -In the simplest instance, all you need to do is pull changes from your
    1.17 -maintenance branch into your local clone of the target branch.
    1.18 +\section{No repita trabajo: fusión entre ramas}
    1.19 +
    1.20 +En muchos casos, cuando tiene un fallo para arreglar en una rama de
    1.21 +mantenimiento, es muy probable que el fallo esté también en la rama
    1.22 +principal( y posiblemente en otras ramas de mantenimiento
    1.23 +también). Solamente un desarrollador extraño desearía corregir el
    1.24 +mismo fallo muchas veces, por tanto, veremos varias alternativas con
    1.25 +las que Mercurial puede ayudarle a administrar tales arreglos de fallo
    1.26 +sin duplicar su trabajo.
    1.27 +
    1.28 +En el caso más sencillo, basta con jalar los cambios de la rama de
    1.29 +mantenimiento a la rama obetivo en su clon local.
    1.30  \interaction{branch-repo.pull}
    1.31 -You'll then need to merge the heads of the two branches, and push back
    1.32 -to the main branch.
    1.33 +A continuación deberá mezclar las cabezas de las dos ramas, y publicar
    1.34 +de nuevo a la rama principal.
    1.35  \interaction{branch-repo.merge}
    1.36  
    1.37 -\section{Naming branches within one repositorio}
    1.38 -
    1.39 -In most instances, isolating branches in repositorios is the right
    1.40 -approach.  Its simplicity makes it easy to understand; and so it's
    1.41 -hard to make mistakes.  There's a one-to-one relationship between
    1.42 -branches you're working in and directories on your system.  This lets
    1.43 -you use normal (non-Mercurial-aware) tools to work on files within a
    1.44 -branch/repositorio.
    1.45 -
    1.46 -If you're more in the ``power user'' category (\emph{and} your
    1.47 -collaborators are too), there is an alternative way of handling
    1.48 -branches that you can consider.  I've already mentioned the
    1.49 -human-level distinction between ``small picture'' and ``big picture''
    1.50 -branches.  While Mercurial works with multiple ``small picture''
    1.51 -branches in a repositorio all the time (for example after you pull
    1.52 -changes in, but before you merge them), it can \emph{also} work with
    1.53 -multiple ``big picture'' branches.
    1.54 -
    1.55 -The key to working this way is that Mercurial lets you assign a
    1.56 -persistent \emph{name} to a branch.  There always exists a branch
    1.57 -named \texttt{default}.  Even before you start naming branches
    1.58 -yourself, you can find traces of the \texttt{default} branch if you
    1.59 -look for them.
    1.60 -
    1.61 -As an example, when you run the \hgcmd{commit} command, and it pops up
    1.62 -your editor so that you can enter a commit message, look for a line
    1.63 -that contains the text ``\texttt{HG: branch default}'' at the bottom.
    1.64 -This is telling you that your commit will occur on the branch named
    1.65 +\section{Nombrar ramas dentro de un repositorio}
    1.66 +
    1.67 +La aproximación correcta en casi todas las oportunidades es aislar las
    1.68 +ramas en los repositorios.  Es fácil de entender gracias a su
    1.69 +facilidad; y es difícil cometer errores. Hay una relación uno a uno
    1.70 +entre las ramas y los directorios con los que está trabajando en su
    1.71 +sistema. Esto le permite usar emplear herramientas usuales(para los
    1.72 +nuevos a Mercurial) para trabajar con los archivos dentro de su
    1.73 +rama/repositorio.
    1.74 +
    1.75 +Si se encuentra más en la categoría ``usuario diestro'' (\emph{y} sus
    1.76 +colaboradores también), puede considerar otra alternativa para
    1.77 +administrar las ramas. He mencionador con anterioridad la distinción a
    1.78 +nivel humano entre las ramas estilo ``cuadro pequeño'' y ``gran
    1.79 +cuadro''.  Mientras que Mercurial trabaja con muchas ramas del estilo
    1.80 +``cuadro pequeño'' en el repositorio todo el tiempo(por ejemplo cuando
    1.81 +usted jala cambios, pero antes de fusionarlos), \emph{también} puede
    1.82 +trabajar con varias ramas del ``cuadro grande''.
    1.83 +
    1.84 +El truco para trabajar de esta forma en Mercurial se logra gracias a
    1.85 +que puede asignar un \emph{nombre} persistente a una rama.  Siempre
    1.86 +existe una rama llamada \texttt{default}.  Incluso antes de que
    1.87 +empiece a nombrar ramas por su cuenta, puede encontrar indicios de la
    1.88 +rama \texttt{default} si los busca.
    1.89 +
    1.90 +Por ejemplo, cuando invoca la orden \hgcmd{commit}, y se lanza su
    1.91 +editor para introducir el mensaje de la consignación, busque la línea
    1.92 +que contiene el texto ``\texttt{HG: branch default}'' al final. Le
    1.93 +está indicando que su consignación ocurrirá en la rama llamada 
    1.94  \texttt{default}.
    1.95  
    1.96 -To start working with named branches, use the \hgcmd{branches}
    1.97 -command.  This command lists the named branches already present in
    1.98 -your repositorio, telling you which changeset is the tip of each.
    1.99 +Use la orden \hgcmd{branches} para comenzar a trabajar con ramas
   1.100 +nombradas. Esta orden mostrará las ramas presentes en su repositorio,
   1.101 +indicándole en qué conjunto de cambios está cada una.
   1.102  \interaction{branch-named.branches}
   1.103 -Since you haven't created any named branches yet, the only one that
   1.104 -exists is \texttt{default}.
   1.105 -
   1.106 -To find out what the ``current'' branch is, run the \hgcmd{branch}
   1.107 -command, giving it no arguments.  This tells you what branch the
   1.108 -parent of the current changeset is on.
   1.109 +Dado que todavía no ha creado ramas nombradas, la única que verá sería
   1.110 +\texttt{default}.
   1.111 +
   1.112 +Para hallar cuál es la rama ``actual'', invoque la orden
   1.113 +\hgcmd{branch}, sin argumento alguno. Le informará en qué rama se
   1.114 +encuentra el padre del conjunto actual de cambios.
   1.115  \interaction{branch-named.branch}
   1.116  
   1.117 -To create a new branch, run the \hgcmd{branch} command again.  This
   1.118 -time, give it one argument: the name of the branch you want to create.
   1.119 +Para crear una nueva rama, invoque la orden \hgcmd{branch} de
   1.120 +nuevo. En esta oportunidad, ofrezca un argumento: el nombre de la rama
   1.121 +que desea crear.
   1.122  \interaction{branch-named.create}
   1.123  
   1.124 -After you've created a branch, you might wonder what effect the
   1.125 -\hgcmd{branch} command has had.  What do the \hgcmd{status} and
   1.126 +Después de crear la rama, usted podría desear ver el efecto que tuvo
   1.127 +la orden \hgcmd{branch}.  ¿Qué reportan las ordenes \hgcmd{status} y
   1.128  \hgcmd{tip} commands report?
   1.129  \interaction{branch-named.status}
   1.130 -Nothing has changed in the working directory, and there's been no new
   1.131 -history created.  As this suggests, running the \hgcmd{branch} command
   1.132 -has no permanent effect; it only tells Mercurial what branch name to
   1.133 -use the \emph{next} time you commit a changeset.
   1.134 -
   1.135 -When you commit a change, Mercurial records the name of the branch on
   1.136 -which you committed.  Once you've switched from the \texttt{default}
   1.137 -branch to another and committed, you'll see the name of the new branch
   1.138 -show up in the output of \hgcmd{log}, \hgcmd{tip}, and other commands
   1.139 -that display the same kind of output.
   1.140 +Nada cambia en el directorio actual, y no se ha añadido nada a la
   1.141 +historia. Esto sugiere que al ejecutar la orden \hgcmd{branch} no hay
   1.142 +un efecto permanente; solamente le indica a que nombre de rama usará
   1.143 +la \emph{próxima} vez que consigne un conjunto de cambios.
   1.144 +
   1.145 +Cuando consigna un cambio, Mercurial alamacena el nombre de la rama en
   1.146 +la cual consignó.  Una vez que haya cambiado de la rama \texttt{default}
   1.147 +y haya consignado, verá que el nombre de la nueva rama se mostrará
   1.148 +cuando use la orden \hgcmd{log}, \hgcmd{tip}, y otras órdenes que
   1.149 +desplieguen la misma clase de información.
   1.150  \interaction{branch-named.commit}
   1.151 -The \hgcmd{log}-like commands will print the branch name of every
   1.152 -changeset that's not on the \texttt{default} branch.  As a result, if
   1.153 -you never use named branches, you'll never see this information.
   1.154 -
   1.155 -Once you've named a branch and committed a change with that name,
   1.156 -every subsequent commit that descends from that change will inherit
   1.157 -the same branch name.  You can change the name of a branch at any
   1.158 -time, using the \hgcmd{branch} command.  
   1.159 +Las órdenes del tipo \hgcmd{log} imprimirán el nombre de la rama de
   1.160 +cualquier conjunto de cambios que no estén en la rama
   1.161 +\texttt{default}. Como resultado, si nunca usa ramas nombradas, nunca
   1.162 +verá esta información.
   1.163 +
   1.164 +Una vez que haya nombrado una rama y consignado un cambio con ese
   1.165 +nombre, todas las consignaciones subsecuentes que desciendan de ese
   1.166 +cambio heredarán el mismo nombre de rama. Puede cambiar el nombre de
   1.167 +una rama en cualquier momento con la orden \hgcmd{branch}.  
   1.168  \interaction{branch-named.rebranch}
   1.169 -In practice, this is something you won't do very often, as branch
   1.170 -names tend to have fairly long lifetimes.  (This isn't a rule, just an
   1.171 -observation.)
   1.172 -
   1.173 -\section{Dealing with multiple named branches in a repositorio}
   1.174 -
   1.175 -If you have more than one named branch in a repositorio, Mercurial will
   1.176 -remember the branch that your working directory on when you start a
   1.177 -command like \hgcmd{update} or \hgcmdargs{pull}{-u}.  It will update
   1.178 -the working directory to the tip of this branch, no matter what the
   1.179 -``repo-wide'' tip is.  To update to a revision that's on a different
   1.180 -named branch, you may need to use the \hgopt{update}{-C} option to
   1.181 -\hgcmd{update}.
   1.182 -
   1.183 -This behaviour is a little subtle, so let's see it in action.  First,
   1.184 -let's remind ourselves what branch we're currently on, and what
   1.185 -branches are in our repositorio.
   1.186 +Esto es algo que no hará muy seguido en la práctica, debido que los
   1.187 +nombres de las ramas tienden a tener vidas largas.  (Esto no es una
   1.188 +regla, solamente una observación.)
   1.189 +
   1.190 +\section{Tratamiento de varias ramas nombradas en un repositorio}
   1.191 +
   1.192 +Si tiene más de una rama nombrada en un repositorio, Mercurial
   1.193 +recordará la rama en la cual está su directorio de trabajo cuando
   1.194 +invoque una orden como \hgcmd{update} o \hgcmdargs{pull}{-u}.  Se
   1.195 +actualizará su directorio de trabajo actual al tip de esta rama, sin
   1.196 +importar cuál sea el tip ``a lo largo del repositorio'' .  Para
   1.197 +actualiar a una revisión que está en una rama con distinto nombre,
   1.198 +puede necesitar la opción \hgopt{update}{-C} de \hgcmd{update}.
   1.199 +
   1.200 +Este comportamiento puede ser sutil, veámoslo en acción.  Primero,
   1.201 +recordemos en qué rama estamos trabajando, y qué ramas están en
   1.202 +nuestro repositorio.
   1.203  \interaction{branch-named.parents}
   1.204 -We're on the \texttt{bar} branch, but there also exists an older
   1.205 -\hgcmd{foo} branch.
   1.206 -
   1.207 -We can \hgcmd{update} back and forth between the tips of the
   1.208 -\texttt{foo} and \texttt{bar} branches without needing to use the
   1.209 -\hgopt{update}{-C} option, because this only involves going backwards
   1.210 -and forwards linearly through our change history.
   1.211 +Estamos en la rama \texttt{bar}, pero existe otra rama más antigua
   1.212 +llamada \hgcmd{foo}.
   1.213 +
   1.214 +Podemos hacer \hgcmd{update} entre los tipos de las ramas \texttt{foo}
   1.215 +y \texttt{bar} sin necesidad de usar la opción \hgopt{update}{-C},
   1.216 +puesto que esto solamente implica ir linealmente hacia adelante y
   1.217 +atrás en nuestra historia de cambios.
   1.218  \interaction{branch-named.update-switchy}
   1.219  
   1.220 -If we go back to the \texttt{foo} branch and then run \hgcmd{update},
   1.221 -it will keep us on \texttt{foo}, not move us to the tip of
   1.222 +Si volvemos a la rama \texttt{foo} e invocamos la orden \hgcmd{update},
   1.223 +nos mantendrá en \texttt{foo}, sin movernos al tipo de \texttt{bar}.
   1.224 +\interaction{branch-named.update-nothing}
   1.225 +
   1.226 +Al consignar un cambio a la rama \texttt{foo} se introducirá una nueva
   1.227 +cabeza.
   1.228 +\interaction{branch-named.foo-commit}
   1.229 +
   1.230 +\section{Nombres de ramas y fusiones}
   1.231 +
   1.232 +Posiblemente ha notado que las fusiones en Mercurial no son simétricas.
   1.233 +Supongamos que su repositorio tiene dos cabezas, 17 and 23.  Si yo invoco
   1.234 +\hgcmd{update} a 17 y aplico \hgcmd{merge} a 23, Mercurial almacena 17
   1.235 +como el primer padre de la fusión, y 23 como el segundo. Mientras que
   1.236 +si hago \hgcmd{update} a 23 y después aplico \hgcmd{merge} con 17,
   1.237 +grabará a 23 como el primer padre, y 17 como el segundo.
   1.238 +
   1.239 +Esto afecta com elige Mercurial el nombre de la rama cuando hace
   1.240 +fusión.  Después de una fusión Mercurial mantendrá el nombre de la
   1.241 +rama del primer padre cuando consigne el resultado de una fusión.  Si
   1.242 +el primer nombre de su padre es \texttt{foo}, y fusiona con
   1.243 +\texttt{bar}, el nombre de la rama continuará siendo \texttt{foo}
   1.244 +después de fusionar.
   1.245 +
   1.246 +No es inusual que un repositorio contenga varias cabezas, cada una con
   1.247 +el mismo nombre de rama.  Digamos que estoy trabajando en la rama
   1.248 +\texttt{foo}, y usted también.  Consignamos cambios distintos; Yo jalo
   1.249 +sus cambios; Ahora tengo dos cabezas, cada una afirmando estar en la
   1.250 +rama \texttt{foo}.  El resultado de una fusión será una única cabeza
   1.251 +en la rama \texttt{foo} como usted esperaría.
   1.252 +
   1.253 +Pero si estoy trabajando en la rama \texttt{bar}, y fusiono el trabajo
   1.254 +desde la rama \texttt{foo}, el resultado permanecerá en la rama
   1.255  \texttt{bar}.
   1.256 -\interaction{branch-named.update-nothing}
   1.257 -
   1.258 -Committing a new change on the \texttt{foo} branch introduces a new
   1.259 -head.
   1.260 -\interaction{branch-named.foo-commit}
   1.261 -
   1.262 -\section{Branch names and merging}
   1.263 -
   1.264 -As you've probably noticed, merges in Mercurial are not symmetrical.
   1.265 -Let's say our repositorio has two heads, 17 and 23.  If I
   1.266 -\hgcmd{update} to 17 and then \hgcmd{merge} with 23, Mercurial records
   1.267 -17 as the first parent of the merge, and 23 as the second.  Whereas if
   1.268 -I \hgcmd{update} to 23 and then \hgcmd{merge} with 17, it records 23
   1.269 -as the first parent, and 17 as the second.
   1.270 -
   1.271 -This affects Mercurial's choice of branch name when you merge.  After
   1.272 -a merge, Mercurial will retain the branch name of the first parent
   1.273 -when you commit the result of the merge.  If your first parent's
   1.274 -branch name is \texttt{foo}, and you merge with \texttt{bar}, the
   1.275 -branch name will still be \texttt{foo} after you merge.
   1.276 -
   1.277 -It's not unusual for a repositorio to contain multiple heads, each with
   1.278 -the same branch name.  Let's say I'm working on the \texttt{foo}
   1.279 -branch, and so are you.  We commit different changes; I pull your
   1.280 -changes; I now have two heads, each claiming to be on the \texttt{foo}
   1.281 -branch.  The result of a merge will be a single head on the
   1.282 -\texttt{foo} branch, as you might hope.
   1.283 -
   1.284 -But if I'm working on the \texttt{bar} branch, and I merge work from
   1.285 -the \texttt{foo} branch, the result will remain on the \texttt{bar}
   1.286 -branch.
   1.287  \interaction{branch-named.merge}
   1.288  
   1.289 -To give a more concrete example, if I'm working on the
   1.290 -\texttt{bleeding-edge} branch, and I want to bring in the latest fixes
   1.291 -from the \texttt{stable} branch, Mercurial will choose the ``right''
   1.292 -(\texttt{bleeding-edge}) branch name when I pull and merge from
   1.293 -\texttt{stable}.
   1.294 -
   1.295 -\section{Branch naming is generally useful}
   1.296 -
   1.297 -You shouldn't think of named branches as applicable only to situations
   1.298 -where you have multiple long-lived branches cohabiting in a single
   1.299 -repositorio.  They're very useful even in the one-branch-per-repositorio
   1.300 -case.  
   1.301 -
   1.302 -In the simplest case, giving a name to each branch gives you a
   1.303 -permanent record of which branch a changeset originated on.  This
   1.304 -gives you more context when you're trying to follow the history of a
   1.305 -long-lived branchy project.
   1.306 -
   1.307 -If you're working with shared repositorios, you can set up a
   1.308 -\hook{pretxnchangegroup} hook on each that will block incoming changes
   1.309 -that have the ``wrong'' branch name.  This provides a simple, but
   1.310 -effective, defence against people accidentally pushing changes from a
   1.311 -``bleeding edge'' branch to a ``stable'' branch.  Such a hook might
   1.312 -look like this inside the shared repo's \hgrc.
   1.313 +En un ejemplo más concreo, si yo estoy trabajando en la rama
   1.314 +\texttt{bleeding-edge}, y deseo traer los arreglos más recientes de la
   1.315 +rama \texttt{estable}, Mercurial elegirá el nombre de rama ``correcto''
   1.316 +(\texttt{bleeding-edge}) cuando yo jale una fusión desde \texttt{estable}.
   1.317 +
   1.318 +\section{Normalmente es útil nombrar ramas}
   1.319 +
   1.320 +No debería considerar que las ramas nombradas son aplicables
   1.321 +únicamente en situaciones con muchas ramas de larga-vida cohabitando
   1.322 +en un mismo repositorio.  Son muy útiles incluso en los casos de
   1.323 +una-rama-por-repositorio.
   1.324 +
   1.325 +En el caso más sencillo, dar un nombre a cada rama ofrece un registro
   1.326 +permanente acerca de en qué conjunto de cambios se generó la rama.
   1.327 +Esto le ofrece más contexto cuando esté tratando de seguir la
   1.328 +historia de un proyecto ramificado de larga vida.
   1.329 +
   1.330 +Si está trabajando con repositorios compartidos, puede configurar el gancho
   1.331 +\hook{pretxnchangegroup} para que cada uno bloquee los cambios con
   1.332 +nombres de rama ``incorrectos'' que están por adicionarse.  Este
   1.333 +provee una defensa sencilla pero efectiva para evitar que la gente
   1.334 +accidentalmente publique cambios de una rama ``super nueva'' a la rama
   1.335 +``estable''.  Tal gancho podría verse de la siguiente forma dentro de
   1.336 +un repositorio compartido de \hgrc.
   1.337  \begin{codesample2}
   1.338    [hooks]
   1.339    pretxnchangegroup.branch = hg heads --template '{branches} ' | grep mybranch