1.1 --- a/es/daily.tex	Sat Oct 25 17:27:51 2008 -0500
     1.2 +++ b/es/daily.tex	Sun Oct 26 07:47:01 2008 -0500
     1.3 @@ -284,106 +284,112 @@
     1.4  \hgcmd{copy}.
     1.5  \interaction{daily.copy.after}
     1.6  
     1.7 -\section{Renaming files}
     1.8 -
     1.9 -It's rather more common to need to rename a file than to make a copy
    1.10 -of it.  The reason I discussed the \hgcmd{copy} command before talking
    1.11 -about renaming files is that Mercurial treats a rename in essentially
    1.12 -the same way as a copy.  Therefore, knowing what Mercurial does when
    1.13 -you copy a file tells you what to expect when you rename a file.
    1.14 -
    1.15 -When you use the \hgcmd{rename} command, Mercurial makes a copy of
    1.16 -each source file, then deletes it and marks the file as removed.
    1.17 +\section{Renombrar ficheros}
    1.18 +
    1.19 +La necesidad de renombrar un fichero es más común que hacer una copia
    1.20 +del fichero.  La razón por la cual discutí la orden \hgcmd{copy} antes
    1.21 +de hablar acerca de cambiar el nombre de los ficheros, es que
    1.22 +Mercurial trata el renombrar un archivo de la misma forma que una
    1.23 +copia.  Por lo tanto, saber lo que hace Mercurial cuando usted copia
    1.24 +un archivo, le indica qué esperar cuando renombra un archivo.
    1.25 +
    1.26 +Cuando usa la orden \hgcmd{rename}, Mercurial hace una copia de cada
    1.27 +archivo fuente, lo borra y lo marca como fichero eliminado.
    1.28  \interaction{daily.rename.rename}
    1.29 -The \hgcmd{status} command shows the newly copied file as added, and
    1.30 -the copied-from file as removed.
    1.31 +La orden \hgcmd{status} muestra la nueva copia del fichero como
    1.32 +añadido y el fichero inicial de la copia, como eliminado.
    1.33  \interaction{daily.rename.status}
    1.34 -As with the results of a \hgcmd{copy}, we must use the
    1.35 -\hgopt{status}{-C} option to \hgcmd{status} to see that the added file
    1.36 -is really being tracked by Mercurial as a copy of the original, now
    1.37 -removed, file.
    1.38 +De la misma forma como se usa la orden \hgcmd{copy}, debemos usar la
    1.39 +opción \hgopt{status}{-C} de la orden \hgcmd{status} para verificar
    1.40 +que el archivo añadido realmente comienza a  ser seguido por Mercurial
    1.41 +como una copia del fichero original, ahora eliminado.
    1.42  \interaction{daily.rename.status-copy}
    1.43  
    1.44 -As with \hgcmd{remove} and \hgcmd{copy}, you can tell Mercurial about
    1.45 -a rename after the fact using the \hgopt{rename}{--after} option.  In
    1.46 -most other respects, the behaviour of the \hgcmd{rename} command, and
    1.47 -the options it accepts, are similar to the \hgcmd{copy} command.
    1.48 -
    1.49 -\subsection{Renaming files and merging changes}
    1.50 -
    1.51 -Since Mercurial's rename is implemented as copy-and-remove, the same
    1.52 -propagation of changes happens when you merge after a rename as after
    1.53 -a copy.
    1.54 -
    1.55 -If I modify a file, and you rename it to a new name, and then we merge
    1.56 -our respective changes, my modifications to the file under its
    1.57 -original name will be propagated into the file under its new name.
    1.58 -(This is something you might expect to ``simply work,'' but not all
    1.59 -revision control systems actually do this.)
    1.60 -
    1.61 -Whereas having changes follow a copy is a feature where you can
    1.62 -perhaps nod and say ``yes, that might be useful,'' it should be clear
    1.63 -that having them follow a rename is definitely important.  Without
    1.64 -this facility, it would simply be too easy for changes to become
    1.65 -orphaned when files are renamed.
    1.66 -
    1.67 -\subsection{Divergent renames and merging}
    1.68 -
    1.69 -The case of diverging names occurs when two developers start with a
    1.70 -file---let's call it \filename{foo}---in their respective
    1.71 -repositories.
    1.72 +Igual que con \hgcmd{remove} y \hgcmd{copy}, puede indicársele a
    1.73 +Mercurial acerca de un renombramiento inmediato con la opción
    1.74 +\hgopt{rename}{--after}.   El comportamiento de la orden
    1.75 +\hgcmd{rename} y las opciones que acepta, son similares a la orden
    1.76 +\hgcmd{copy} en casi todo.
    1.77 +
    1.78 +\subsection{Renombrar ficheros y fusionar cambios}
    1.79 +
    1.80 +Dado que el renombrar de Mercurial se implementa como un
    1.81 +copiar-y-eliminar, la misma propagación de cambios ocurre cuando usted
    1.82 +fusiona después de renombrar como después de hacer una copia.
    1.83 +
    1.84 +Si Yo modifico un fichero y usted lo renombra a un nuevo archivo, y
    1.85 +posteriormente fusionamos nuestros cambios respectivos, mi
    1.86 +modificación al fichero bajo su nombre original se propagará en el
    1.87 +fichero con el nuevo nombre. (Es lo que se esperaría como ``lo hace,''
    1.88 +pero, no todos los sistemas de control de revisiones lo logran.)
    1.89 +
    1.90 +El hecho de que los cambios sigan la copia es una característica que
    1.91 +puede subestimar diciendo ``si, puede ser útil,'' debería ser claro
    1.92 +que el seguimiento de cambios de un renombramiento es importante
    1.93 +definitivamente.  Sin esto, sería muy sencillo que los cambios se
    1.94 +volvieran huérfanos cuando los archivos se renombran.
    1.95 +
    1.96 +\subsection{Cambios de nombre divergentes y fusión}
    1.97 +
    1.98 +El caso de renombramiento con nombres divergentes ocurre cuando dos
    1.99 +desarrolladores comienzan  con un fichero---llamémoslo
   1.100 +\filename{foo}---en sus repositorios respectivos.
   1.101  
   1.102  \interaction{rename.divergent.clone}
   1.103 -Anne renames the file to \filename{bar}.
   1.104 +Ana renombra el fichero a \filename{bar}.
   1.105  \interaction{rename.divergent.rename.anne}
   1.106 -Meanwhile, Bob renames it to \filename{quux}.
   1.107 +Mientras que Roberto lo renombra como \filename{quux}.
   1.108  \interaction{rename.divergent.rename.bob}
   1.109  
   1.110 -I like to think of this as a conflict because each developer has
   1.111 -expressed different intentions about what the file ought to be named.
   1.112 -
   1.113 -What do you think should happen when they merge their work?
   1.114 -Mercurial's actual behaviour is that it always preserves \emph{both}
   1.115 -names when it merges changesets that contain divergent renames.
   1.116 +Veo esto como un conflicto porque cada desarrollador ha expresado
   1.117 +intenciones diferentes acerca de cómo considera debería haberse
   1.118 +renombrado el fichero.
   1.119 +
   1.120 +¿ué cree que debería pasar cuando fusionen su trabajo?
   1.121 +El comportamiento de Mercurial es que siempre preserva \emph{ambos}
   1.122 +nombres cuando fusiona  los conjuntos de cambios que contienen nombres
   1.123 +divergentes.
   1.124  \interaction{rename.divergent.merge}
   1.125  
   1.126 -Notice that Mercurial does warn about the divergent renames, but it
   1.127 -leaves it up to you to do something about the divergence after the merge.
   1.128 -
   1.129 -\subsection{Convergent renames and merging}
   1.130 -
   1.131 -Another kind of rename conflict occurs when two people choose to
   1.132 -rename different \emph{source} files to the same \emph{destination}.
   1.133 -In this case, Mercurial runs its normal merge machinery, and lets you
   1.134 -guide it to a suitable resolution.
   1.135 -
   1.136 -\subsection{Other name-related corner cases}
   1.137 -
   1.138 -Mercurial has a longstanding bug in which it fails to handle a merge
   1.139 -where one side has a file with a given name, while another has a
   1.140 -directory with the same name.  This is documented as~\bug{29}.
   1.141 +Tenga en cuenta que Mercurial le advierte acerca de nombres
   1.142 +divergentes, pero deja que usted decida qué hacer con la divergencia
   1.143 +después de la fusión.
   1.144 +
   1.145 +\subsection{Cambios de nombre convergentes y fusión}
   1.146 +
   1.147 +Otra clase de conflicto al cambiar el nombre ocurre cuando dos
   1.148 +personas eligen renombrar diferentes ficheros \emph{fuente} al mismo
   1.149 +\emph{destino}. En este caso Mercurial aplica su maquinaria de fusión
   1.150 +usual, y le permite a usted guiarlo a una solución adecuada.
   1.151 +
   1.152 +\subsection{Otros casos límites relacionados con renombramientos}
   1.153 +
   1.154 +Mercurial tiene un fallo de mucho tiempo en el cual no es capaz de
   1.155 +fusionar cuando por un lado hay un archivo con un nombre dado,
   1.156 +mientras que en otro hay un directorio con el mismo nombre. Esto está
   1.157 +documentado como~\bug{29}.
   1.158  \interaction{issue29.go}
   1.159  
   1.160 -\section{Recovering from mistakes}
   1.161 -
   1.162 -Mercurial has some useful commands that will help you to recover from
   1.163 -some common mistakes.
   1.164 -
   1.165 -The \hgcmd{revert} command lets you undo changes that you have made to
   1.166 -your working directory.  For example, if you \hgcmd{add} a file by
   1.167 -accident, just run \hgcmd{revert} with the name of the file you added,
   1.168 -and while the file won't be touched in any way, it won't be tracked
   1.169 -for adding by Mercurial any longer, either.  You can also use
   1.170 -\hgcmd{revert} to get rid of erroneous changes to a file.
   1.171 -
   1.172 -It's useful to remember that the \hgcmd{revert} command is useful for
   1.173 -changes that you have not yet committed.  Once you've committed a
   1.174 -change, if you decide it was a mistake, you can still do something
   1.175 -about it, though your options may be more limited.
   1.176 -
   1.177 -For more information about the \hgcmd{revert} command, and details
   1.178 -about how to deal with changes you have already committed, see
   1.179 -chapter~\ref{chap:undo}.
   1.180 +\section{Recuperarse de equivocaciones}
   1.181 +
   1.182 +Mercurial tiene unas órdenes poderosas que le ayudarán a recuperarse
   1.183 +de equivocaciones comunes.
   1.184 +
   1.185 +La orden \hgcmd{revert} le permite deshacer cambios que haya hecho a
   1.186 +su directorio de trabajo. Por ejemplo, Si aplicó \hgcmd{add} a un
   1.187 +fichero por accidente, ejecute \hgcmd{revert} con el nombre del
   1.188 +fichero que añadió, y en tando que el archivo no haya sido tocado de
   1.189 +forma alguna, no será adicionado, ni seguido por Mercurial.  También
   1.190 +puede usar \hgcmd{revert} para deshacerse de cambios erróneos a un
   1.191 +fichero.
   1.192 +
   1.193 +Tenga en cuenta que la orden \hgcmd{revert} se usa para cambios que no
   1.194 +han sido consignados. Cuando haya consignado un cambio, si decide que
   1.195 +era un error, puede hacer algo todavía, pero sus opciones pueden ser
   1.196 +más limitadas.
   1.197 +
   1.198 +Para obtener información acerca de la orden \hgcmd{revert} y detalles
   1.199 +de cómo tratar con cambios consignados, vea el capítulo~\ref{chap:undo}.
   1.200  
   1.201  %%% Local Variables: 
   1.202  %%% mode: latex