1.1 --- a/es/00book.tex	Sat Oct 18 23:29:33 2008 -0500
     1.2 +++ b/es/00book.tex	Sun Oct 19 17:08:11 2008 -0500
     1.3 @@ -17,16 +17,16 @@
     1.4  
     1.5  \include{99defs}
     1.6  
     1.7 -\title{Control de Revisiones Distribuido con Mercurial} \author{Bryan
     1.8 +\title{Control Distribuido de Revisiones con Mercurial} \author{Bryan
     1.9    O'Sullivan}
    1.10  \date{Copyright \copyright\ 2006, 2007 Bryan O'Sullivan.\\
    1.11    Este material puede distribuirse únicamente bajo los términos y
    1.12    condiciones establecidos en la versión 1.0 de la Licencia de Publicación
    1.13 -  Abierta(OPL) Refiérase por favor al apéndice~\ref{cha:opl} en busca del
    1.14 +  Abierta(OPL) Refiérase por favor al apéndice~\ref{cha:opl} para encontrar el
    1.15    texto de la licencia.\\
    1.16 -  Este libro fue preparado desde
    1.17 +  Este libro fue preparado a partir de
    1.18    \href{http://hg.serpentine.com/mercurial/book/}{rev~\input{build_id}}
    1.19 -  haciendo uso de Mercurial \href{http://www.selenic.com/hg/}{rev~\input{hg_id}}.}
    1.20 +  usando Mercurial \href{http://www.selenic.com/hg/}{rev~\input{hg_id}}.}
    1.21  
    1.22  \makeindex
    1.23  

     2.1 --- a/es/Leame.1st	Sat Oct 18 23:29:33 2008 -0500
     2.2 +++ b/es/Leame.1st	Sun Oct 19 17:08:11 2008 -0500
     2.3 @@ -28,13 +28,16 @@
     2.4  de ortografía son siempre bienvenidos.
     2.5  
     2.6  == Archivos en proceso de traducción ==
     2.7 -||'''archivo''''||'''traductor'''||'''Estado'''||'''Inicio'''||
     2.8 -|| branch.tex   || Igor Támara   ||    50%     || 16/10/2008 ||
     2.9 -|| preface.tex  || Javier Rojas  ||    25%     || 18/10/2008 ||
    2.10 -Su elección aquí
    2.11 +||'''archivo''''||'''traductor'''||'''Estado'''||'''Inicio'''||  '''Fin'''  ||
    2.12 +|| 00book.tex   || Igor Támara   ||    100%    || 16/10/2008 ||  16/10/2008 ||
    2.13 +|| branch.tex   || Igor Támara   ||    100%    || 16/10/2008 ||  19/10/2008 ||
    2.14 +|| preface.tex  || Javier Rojas  ||    25%     || 18/10/2008 ||             ||
    2.15  
    2.16  == Archivos en proceso de revisión ==
    2.17 -Su elección aquí
    2.18 +||'''archivo''''|| '''revisor''' ||'''Estado'''||'''Inicio'''||  '''Fin'''  ||
    2.19 +|| 00book.tex   ||               ||            ||            ||             ||
    2.20 +|| branch.tex   ||               ||            ||            ||             ||
    2.21 +
    2.22  
    2.23  == Archivos terminados ==
    2.24  
    2.25 @@ -47,10 +50,13 @@
    2.26   Changeset: Conjunto de Cambios
    2.27   Command: Orden
    2.28   Commit: Consignar
    2.29 + File: Archivo
    2.30   Head: Principal
    2.31 + Hook: Gancho
    2.32   Merge: Fusión
    2.33   Milestone: Etapa
    2.34   Patch: Parche
    2.35 + Pull: Jalar
    2.36   Push: Publicar
    2.37   Release: Versión o liberación de versión
    2.38   Revlog: Bitácora de revisiones

     3.1 --- a/es/branch.tex	Sat Oct 18 23:29:33 2008 -0500
     3.2 +++ b/es/branch.tex	Sun Oct 19 17:08:11 2008 -0500
     3.3 @@ -220,179 +220,183 @@
     3.4  continuar asilada e incólume, en el repositorio \texttt{myproject}.
     3.5  \interaction{branch-repo.new}
     3.6  
     3.7 -\section{Don't repeat yourself: merging across branches}
     3.8 -
     3.9 -In many cases, if you have a bug to fix on a maintenance branch, the
    3.10 -chances are good that the bug exists on your project's main branch
    3.11 -(and possibly other maintenance branches, too).  It's a rare developer
    3.12 -who wants to fix the same bug multiple times, so let's look at a few
    3.13 -ways that Mercurial can help you to manage these bugfixes without
    3.14 -duplicating your work.
    3.15 -
    3.16 -In the simplest instance, all you need to do is pull changes from your
    3.17 -maintenance branch into your local clone of the target branch.
    3.18 +\section{No repita trabajo: fusión entre ramas}
    3.19 +
    3.20 +En muchos casos, cuando tiene un fallo para arreglar en una rama de
    3.21 +mantenimiento, es muy probable que el fallo esté también en la rama
    3.22 +principal( y posiblemente en otras ramas de mantenimiento
    3.23 +también). Solamente un desarrollador extraño desearía corregir el
    3.24 +mismo fallo muchas veces, por tanto, veremos varias alternativas con
    3.25 +las que Mercurial puede ayudarle a administrar tales arreglos de fallo
    3.26 +sin duplicar su trabajo.
    3.27 +
    3.28 +En el caso más sencillo, basta con jalar los cambios de la rama de
    3.29 +mantenimiento a la rama obetivo en su clon local.
    3.30  \interaction{branch-repo.pull}
    3.31 -You'll then need to merge the heads of the two branches, and push back
    3.32 -to the main branch.
    3.33 +A continuación deberá mezclar las cabezas de las dos ramas, y publicar
    3.34 +de nuevo a la rama principal.
    3.35  \interaction{branch-repo.merge}
    3.36  
    3.37 -\section{Naming branches within one repositorio}
    3.38 -
    3.39 -In most instances, isolating branches in repositorios is the right
    3.40 -approach.  Its simplicity makes it easy to understand; and so it's
    3.41 -hard to make mistakes.  There's a one-to-one relationship between
    3.42 -branches you're working in and directories on your system.  This lets
    3.43 -you use normal (non-Mercurial-aware) tools to work on files within a
    3.44 -branch/repositorio.
    3.45 -
    3.46 -If you're more in the ``power user'' category (\emph{and} your
    3.47 -collaborators are too), there is an alternative way of handling
    3.48 -branches that you can consider.  I've already mentioned the
    3.49 -human-level distinction between ``small picture'' and ``big picture''
    3.50 -branches.  While Mercurial works with multiple ``small picture''
    3.51 -branches in a repositorio all the time (for example after you pull
    3.52 -changes in, but before you merge them), it can \emph{also} work with
    3.53 -multiple ``big picture'' branches.
    3.54 -
    3.55 -The key to working this way is that Mercurial lets you assign a
    3.56 -persistent \emph{name} to a branch.  There always exists a branch
    3.57 -named \texttt{default}.  Even before you start naming branches
    3.58 -yourself, you can find traces of the \texttt{default} branch if you
    3.59 -look for them.
    3.60 -
    3.61 -As an example, when you run the \hgcmd{commit} command, and it pops up
    3.62 -your editor so that you can enter a commit message, look for a line
    3.63 -that contains the text ``\texttt{HG: branch default}'' at the bottom.
    3.64 -This is telling you that your commit will occur on the branch named
    3.65 +\section{Nombrar ramas dentro de un repositorio}
    3.66 +
    3.67 +La aproximación correcta en casi todas las oportunidades es aislar las
    3.68 +ramas en los repositorios.  Es fácil de entender gracias a su
    3.69 +facilidad; y es difícil cometer errores. Hay una relación uno a uno
    3.70 +entre las ramas y los directorios con los que está trabajando en su
    3.71 +sistema. Esto le permite usar emplear herramientas usuales(para los
    3.72 +nuevos a Mercurial) para trabajar con los archivos dentro de su
    3.73 +rama/repositorio.
    3.74 +
    3.75 +Si se encuentra más en la categoría ``usuario diestro'' (\emph{y} sus
    3.76 +colaboradores también), puede considerar otra alternativa para
    3.77 +administrar las ramas. He mencionador con anterioridad la distinción a
    3.78 +nivel humano entre las ramas estilo ``cuadro pequeño'' y ``gran
    3.79 +cuadro''.  Mientras que Mercurial trabaja con muchas ramas del estilo
    3.80 +``cuadro pequeño'' en el repositorio todo el tiempo(por ejemplo cuando
    3.81 +usted jala cambios, pero antes de fusionarlos), \emph{también} puede
    3.82 +trabajar con varias ramas del ``cuadro grande''.
    3.83 +
    3.84 +El truco para trabajar de esta forma en Mercurial se logra gracias a
    3.85 +que puede asignar un \emph{nombre} persistente a una rama.  Siempre
    3.86 +existe una rama llamada \texttt{default}.  Incluso antes de que
    3.87 +empiece a nombrar ramas por su cuenta, puede encontrar indicios de la
    3.88 +rama \texttt{default} si los busca.
    3.89 +
    3.90 +Por ejemplo, cuando invoca la orden \hgcmd{commit}, y se lanza su
    3.91 +editor para introducir el mensaje de la consignación, busque la línea
    3.92 +que contiene el texto ``\texttt{HG: branch default}'' al final. Le
    3.93 +está indicando que su consignación ocurrirá en la rama llamada 
    3.94  \texttt{default}.
    3.95  
    3.96 -To start working with named branches, use the \hgcmd{branches}
    3.97 -command.  This command lists the named branches already present in
    3.98 -your repositorio, telling you which changeset is the tip of each.
    3.99 +Use la orden \hgcmd{branches} para comenzar a trabajar con ramas
   3.100 +nombradas. Esta orden mostrará las ramas presentes en su repositorio,
   3.101 +indicándole en qué conjunto de cambios está cada una.
   3.102  \interaction{branch-named.branches}
   3.103 -Since you haven't created any named branches yet, the only one that
   3.104 -exists is \texttt{default}.
   3.105 -
   3.106 -To find out what the ``current'' branch is, run the \hgcmd{branch}
   3.107 -command, giving it no arguments.  This tells you what branch the
   3.108 -parent of the current changeset is on.
   3.109 +Dado que todavía no ha creado ramas nombradas, la única que verá sería
   3.110 +\texttt{default}.
   3.111 +
   3.112 +Para hallar cuál es la rama ``actual'', invoque la orden
   3.113 +\hgcmd{branch}, sin argumento alguno. Le informará en qué rama se
   3.114 +encuentra el padre del conjunto actual de cambios.
   3.115  \interaction{branch-named.branch}
   3.116  
   3.117 -To create a new branch, run the \hgcmd{branch} command again.  This
   3.118 -time, give it one argument: the name of the branch you want to create.
   3.119 +Para crear una nueva rama, invoque la orden \hgcmd{branch} de
   3.120 +nuevo. En esta oportunidad, ofrezca un argumento: el nombre de la rama
   3.121 +que desea crear.
   3.122  \interaction{branch-named.create}
   3.123  
   3.124 -After you've created a branch, you might wonder what effect the
   3.125 -\hgcmd{branch} command has had.  What do the \hgcmd{status} and
   3.126 +Después de crear la rama, usted podría desear ver el efecto que tuvo
   3.127 +la orden \hgcmd{branch}.  ¿Qué reportan las ordenes \hgcmd{status} y
   3.128  \hgcmd{tip} commands report?
   3.129  \interaction{branch-named.status}
   3.130 -Nothing has changed in the working directory, and there's been no new
   3.131 -history created.  As this suggests, running the \hgcmd{branch} command
   3.132 -has no permanent effect; it only tells Mercurial what branch name to
   3.133 -use the \emph{next} time you commit a changeset.
   3.134 -
   3.135 -When you commit a change, Mercurial records the name of the branch on
   3.136 -which you committed.  Once you've switched from the \texttt{default}
   3.137 -branch to another and committed, you'll see the name of the new branch
   3.138 -show up in the output of \hgcmd{log}, \hgcmd{tip}, and other commands
   3.139 -that display the same kind of output.
   3.140 +Nada cambia en el directorio actual, y no se ha añadido nada a la
   3.141 +historia. Esto sugiere que al ejecutar la orden \hgcmd{branch} no hay
   3.142 +un efecto permanente; solamente le indica a que nombre de rama usará
   3.143 +la \emph{próxima} vez que consigne un conjunto de cambios.
   3.144 +
   3.145 +Cuando consigna un cambio, Mercurial alamacena el nombre de la rama en
   3.146 +la cual consignó.  Una vez que haya cambiado de la rama \texttt{default}
   3.147 +y haya consignado, verá que el nombre de la nueva rama se mostrará
   3.148 +cuando use la orden \hgcmd{log}, \hgcmd{tip}, y otras órdenes que
   3.149 +desplieguen la misma clase de información.
   3.150  \interaction{branch-named.commit}
   3.151 -The \hgcmd{log}-like commands will print the branch name of every
   3.152 -changeset that's not on the \texttt{default} branch.  As a result, if
   3.153 -you never use named branches, you'll never see this information.
   3.154 -
   3.155 -Once you've named a branch and committed a change with that name,
   3.156 -every subsequent commit that descends from that change will inherit
   3.157 -the same branch name.  You can change the name of a branch at any
   3.158 -time, using the \hgcmd{branch} command.  
   3.159 +Las órdenes del tipo \hgcmd{log} imprimirán el nombre de la rama de
   3.160 +cualquier conjunto de cambios que no estén en la rama
   3.161 +\texttt{default}. Como resultado, si nunca usa ramas nombradas, nunca
   3.162 +verá esta información.
   3.163 +
   3.164 +Una vez que haya nombrado una rama y consignado un cambio con ese
   3.165 +nombre, todas las consignaciones subsecuentes que desciendan de ese
   3.166 +cambio heredarán el mismo nombre de rama. Puede cambiar el nombre de
   3.167 +una rama en cualquier momento con la orden \hgcmd{branch}.  
   3.168  \interaction{branch-named.rebranch}
   3.169 -In practice, this is something you won't do very often, as branch
   3.170 -names tend to have fairly long lifetimes.  (This isn't a rule, just an
   3.171 -observation.)
   3.172 -
   3.173 -\section{Dealing with multiple named branches in a repositorio}
   3.174 -
   3.175 -If you have more than one named branch in a repositorio, Mercurial will
   3.176 -remember the branch that your working directory on when you start a
   3.177 -command like \hgcmd{update} or \hgcmdargs{pull}{-u}.  It will update
   3.178 -the working directory to the tip of this branch, no matter what the
   3.179 -``repo-wide'' tip is.  To update to a revision that's on a different
   3.180 -named branch, you may need to use the \hgopt{update}{-C} option to
   3.181 -\hgcmd{update}.
   3.182 -
   3.183 -This behaviour is a little subtle, so let's see it in action.  First,
   3.184 -let's remind ourselves what branch we're currently on, and what
   3.185 -branches are in our repositorio.
   3.186 +Esto es algo que no hará muy seguido en la práctica, debido que los
   3.187 +nombres de las ramas tienden a tener vidas largas.  (Esto no es una
   3.188 +regla, solamente una observación.)
   3.189 +
   3.190 +\section{Tratamiento de varias ramas nombradas en un repositorio}
   3.191 +
   3.192 +Si tiene más de una rama nombrada en un repositorio, Mercurial
   3.193 +recordará la rama en la cual está su directorio de trabajo cuando
   3.194 +invoque una orden como \hgcmd{update} o \hgcmdargs{pull}{-u}.  Se
   3.195 +actualizará su directorio de trabajo actual al tip de esta rama, sin
   3.196 +importar cuál sea el tip ``a lo largo del repositorio'' .  Para
   3.197 +actualiar a una revisión que está en una rama con distinto nombre,
   3.198 +puede necesitar la opción \hgopt{update}{-C} de \hgcmd{update}.
   3.199 +
   3.200 +Este comportamiento puede ser sutil, veámoslo en acción.  Primero,
   3.201 +recordemos en qué rama estamos trabajando, y qué ramas están en
   3.202 +nuestro repositorio.
   3.203  \interaction{branch-named.parents}
   3.204 -We're on the \texttt{bar} branch, but there also exists an older
   3.205 -\hgcmd{foo} branch.
   3.206 -
   3.207 -We can \hgcmd{update} back and forth between the tips of the
   3.208 -\texttt{foo} and \texttt{bar} branches without needing to use the
   3.209 -\hgopt{update}{-C} option, because this only involves going backwards
   3.210 -and forwards linearly through our change history.
   3.211 +Estamos en la rama \texttt{bar}, pero existe otra rama más antigua
   3.212 +llamada \hgcmd{foo}.
   3.213 +
   3.214 +Podemos hacer \hgcmd{update} entre los tipos de las ramas \texttt{foo}
   3.215 +y \texttt{bar} sin necesidad de usar la opción \hgopt{update}{-C},
   3.216 +puesto que esto solamente implica ir linealmente hacia adelante y
   3.217 +atrás en nuestra historia de cambios.
   3.218  \interaction{branch-named.update-switchy}
   3.219  
   3.220 -If we go back to the \texttt{foo} branch and then run \hgcmd{update},
   3.221 -it will keep us on \texttt{foo}, not move us to the tip of
   3.222 +Si volvemos a la rama \texttt{foo} e invocamos la orden \hgcmd{update},
   3.223 +nos mantendrá en \texttt{foo}, sin movernos al tipo de \texttt{bar}.
   3.224 +\interaction{branch-named.update-nothing}
   3.225 +
   3.226 +Al consignar un cambio a la rama \texttt{foo} se introducirá una nueva
   3.227 +cabeza.
   3.228 +\interaction{branch-named.foo-commit}
   3.229 +
   3.230 +\section{Nombres de ramas y fusiones}
   3.231 +
   3.232 +Posiblemente ha notado que las fusiones en Mercurial no son simétricas.
   3.233 +Supongamos que su repositorio tiene dos cabezas, 17 and 23.  Si yo invoco
   3.234 +\hgcmd{update} a 17 y aplico \hgcmd{merge} a 23, Mercurial almacena 17
   3.235 +como el primer padre de la fusión, y 23 como el segundo. Mientras que
   3.236 +si hago \hgcmd{update} a 23 y después aplico \hgcmd{merge} con 17,
   3.237 +grabará a 23 como el primer padre, y 17 como el segundo.
   3.238 +
   3.239 +Esto afecta com elige Mercurial el nombre de la rama cuando hace
   3.240 +fusión.  Después de una fusión Mercurial mantendrá el nombre de la
   3.241 +rama del primer padre cuando consigne el resultado de una fusión.  Si
   3.242 +el primer nombre de su padre es \texttt{foo}, y fusiona con
   3.243 +\texttt{bar}, el nombre de la rama continuará siendo \texttt{foo}
   3.244 +después de fusionar.
   3.245 +
   3.246 +No es inusual que un repositorio contenga varias cabezas, cada una con
   3.247 +el mismo nombre de rama.  Digamos que estoy trabajando en la rama
   3.248 +\texttt{foo}, y usted también.  Consignamos cambios distintos; Yo jalo
   3.249 +sus cambios; Ahora tengo dos cabezas, cada una afirmando estar en la
   3.250 +rama \texttt{foo}.  El resultado de una fusión será una única cabeza
   3.251 +en la rama \texttt{foo} como usted esperaría.
   3.252 +
   3.253 +Pero si estoy trabajando en la rama \texttt{bar}, y fusiono el trabajo
   3.254 +desde la rama \texttt{foo}, el resultado permanecerá en la rama
   3.255  \texttt{bar}.
   3.256 -\interaction{branch-named.update-nothing}
   3.257 -
   3.258 -Committing a new change on the \texttt{foo} branch introduces a new
   3.259 -head.
   3.260 -\interaction{branch-named.foo-commit}
   3.261 -
   3.262 -\section{Branch names and merging}
   3.263 -
   3.264 -As you've probably noticed, merges in Mercurial are not symmetrical.
   3.265 -Let's say our repositorio has two heads, 17 and 23.  If I
   3.266 -\hgcmd{update} to 17 and then \hgcmd{merge} with 23, Mercurial records
   3.267 -17 as the first parent of the merge, and 23 as the second.  Whereas if
   3.268 -I \hgcmd{update} to 23 and then \hgcmd{merge} with 17, it records 23
   3.269 -as the first parent, and 17 as the second.
   3.270 -
   3.271 -This affects Mercurial's choice of branch name when you merge.  After
   3.272 -a merge, Mercurial will retain the branch name of the first parent
   3.273 -when you commit the result of the merge.  If your first parent's
   3.274 -branch name is \texttt{foo}, and you merge with \texttt{bar}, the
   3.275 -branch name will still be \texttt{foo} after you merge.
   3.276 -
   3.277 -It's not unusual for a repositorio to contain multiple heads, each with
   3.278 -the same branch name.  Let's say I'm working on the \texttt{foo}
   3.279 -branch, and so are you.  We commit different changes; I pull your
   3.280 -changes; I now have two heads, each claiming to be on the \texttt{foo}
   3.281 -branch.  The result of a merge will be a single head on the
   3.282 -\texttt{foo} branch, as you might hope.
   3.283 -
   3.284 -But if I'm working on the \texttt{bar} branch, and I merge work from
   3.285 -the \texttt{foo} branch, the result will remain on the \texttt{bar}
   3.286 -branch.
   3.287  \interaction{branch-named.merge}
   3.288  
   3.289 -To give a more concrete example, if I'm working on the
   3.290 -\texttt{bleeding-edge} branch, and I want to bring in the latest fixes
   3.291 -from the \texttt{stable} branch, Mercurial will choose the ``right''
   3.292 -(\texttt{bleeding-edge}) branch name when I pull and merge from
   3.293 -\texttt{stable}.
   3.294 -
   3.295 -\section{Branch naming is generally useful}
   3.296 -
   3.297 -You shouldn't think of named branches as applicable only to situations
   3.298 -where you have multiple long-lived branches cohabiting in a single
   3.299 -repositorio.  They're very useful even in the one-branch-per-repositorio
   3.300 -case.  
   3.301 -
   3.302 -In the simplest case, giving a name to each branch gives you a
   3.303 -permanent record of which branch a changeset originated on.  This
   3.304 -gives you more context when you're trying to follow the history of a
   3.305 -long-lived branchy project.
   3.306 -
   3.307 -If you're working with shared repositorios, you can set up a
   3.308 -\hook{pretxnchangegroup} hook on each that will block incoming changes
   3.309 -that have the ``wrong'' branch name.  This provides a simple, but
   3.310 -effective, defence against people accidentally pushing changes from a
   3.311 -``bleeding edge'' branch to a ``stable'' branch.  Such a hook might
   3.312 -look like this inside the shared repo's \hgrc.
   3.313 +En un ejemplo más concreo, si yo estoy trabajando en la rama
   3.314 +\texttt{bleeding-edge}, y deseo traer los arreglos más recientes de la
   3.315 +rama \texttt{estable}, Mercurial elegirá el nombre de rama ``correcto''
   3.316 +(\texttt{bleeding-edge}) cuando yo jale una fusión desde \texttt{estable}.
   3.317 +
   3.318 +\section{Normalmente es útil nombrar ramas}
   3.319 +
   3.320 +No debería considerar que las ramas nombradas son aplicables
   3.321 +únicamente en situaciones con muchas ramas de larga-vida cohabitando
   3.322 +en un mismo repositorio.  Son muy útiles incluso en los casos de
   3.323 +una-rama-por-repositorio.
   3.324 +
   3.325 +En el caso más sencillo, dar un nombre a cada rama ofrece un registro
   3.326 +permanente acerca de en qué conjunto de cambios se generó la rama.
   3.327 +Esto le ofrece más contexto cuando esté tratando de seguir la
   3.328 +historia de un proyecto ramificado de larga vida.
   3.329 +
   3.330 +Si está trabajando con repositorios compartidos, puede configurar el gancho
   3.331 +\hook{pretxnchangegroup} para que cada uno bloquee los cambios con
   3.332 +nombres de rama ``incorrectos'' que están por adicionarse.  Este
   3.333 +provee una defensa sencilla pero efectiva para evitar que la gente
   3.334 +accidentalmente publique cambios de una rama ``super nueva'' a la rama
   3.335 +``estable''.  Tal gancho podría verse de la siguiente forma dentro de
   3.336 +un repositorio compartido de \hgrc.
   3.337  \begin{codesample2}
   3.338    [hooks]
   3.339    pretxnchangegroup.branch = hg heads --template '{branches} ' | grep mybranch