hgbook
annotate es/daily.tex @ 1114:527b86d55d4a
inotify: update installation information
inotify is shipped in Mercurial since 1.0, which greatly simplifies the installation process
inotify is shipped in Mercurial since 1.0, which greatly simplifies the installation process
author | Nicolas Dumazet <nicdumz.commits@gmail.com> |
---|---|
date | Sun Dec 13 16:35:56 2009 +0900 (2009-12-13) |
parents | 193d107798cc |
children |
rev | line source |
---|---|
igor@345 | 1 \chapter{Mercurial día a día} |
igor@345 | 2 \label{chap:daily} |
igor@345 | 3 |
igor@359 | 4 \section{Cómo indicarle a Mercurial qué ficheros seguir} |
igor@359 | 5 |
igor@359 | 6 Mercurial no trabaja con ficheros en su repositorio a menos que usted |
jerojasro@535 | 7 se lo indique explícitamente. La orden \hgcmd{status} le mostrará |
jerojasro@535 | 8 cuáles ficheros son desconocidos para Mercurial; se emplea un |
igor@359 | 9 ``\texttt{?}'' para mostrar tales ficheros. |
igor@359 | 10 |
igor@359 | 11 Para indicarle a Mercurial que tenga en cuenta un fichero, emplee la |
igor@359 | 12 orden \hgcmd{add}. Una vez que haya adicionado el fichero, la línea |
igor@359 | 13 referente al fichero al aplicar la orden \hgcmd{status} para tal |
igor@359 | 14 fichero cambia de ``\texttt{?}'' a ``\texttt{A}''. |
igor@345 | 15 \interaction{daily.files.add} |
igor@345 | 16 |
igor@359 | 17 Después de invocar \hgcmd{commit}, los ficheros que haya adicionado |
igor@345 | 18 antes de consignar no se listarán en la salida de \hgcmd{status}. La |
igor@345 | 19 razón para esto es que \hgcmd{status} solamente le muestra aquellos |
jerojasro@540 | 20 ficheros ``interesantes'' ---~los que usted haya modificado o a aquellos |
jerojasro@540 | 21 sobre los que usted haya indicado a Mercurial hacer algo--- de forma |
igor@345 | 22 predeterminada. Si tiene un repositorio que contiene miles de |
jerojasro@536 | 23 ficheros, rara vez deseará saber cuáles de ellos están siendo |
igor@345 | 24 seguidos por Mercurial, pero que no han cambiado. (De todas maneras, |
igor@345 | 25 puede obtener tal información; más adelante hablaremos de ello.) |
igor@345 | 26 |
igor@345 | 27 |
jerojasro@361 | 28 Cuando usted añade un fichero, Mercurial no hace nada con él inmediatamente. |
jerojasro@536 | 29 En cambio, tomará una instantánea del estado del fichero la próxima vez |
igor@345 | 30 que usted consigne. Continuará haciendo seguimiento a los cambios que |
igor@359 | 31 haga sobre el fichero cada vez que consigne, hasta que usted lo elimine. |
igor@359 | 32 |
jerojasro@535 | 33 \subsection{Nombramiento explícito e implícito de ficheros} |
igor@345 | 34 |
igor@345 | 35 Mercurial tiene un comportamiento útil en el cual si a una orden, |
jerojasro@536 | 36 le pasa el nombre de un directorio, todas las órdenes lo interpretarán como |
igor@359 | 37 ``Deseo operar en cada fichero de este directorio y sus |
igor@345 | 38 subdirectorios''. |
igor@345 | 39 \interaction{daily.files.add-dir} |
igor@345 | 40 Tenga en cuenta que en este ejemplo Mercurial imprimió los nombres de |
igor@359 | 41 los ficheros que se adicionaron, mientras que no lo hizo en el ejemplo |
igor@359 | 42 anterior cuando adicionamos el fichero con nombre \filename{a}. |
igor@359 | 43 |
igor@359 | 44 En el último caso hicimos explícito el nombre del fichero que |
igor@345 | 45 deseábamos adicionar en la línea de órdenes, y Mercurial asume en |
igor@345 | 46 tales casos que usted sabe lo que está haciendo y no imprime |
igor@345 | 47 información alguna. |
igor@345 | 48 |
igor@359 | 49 Cuando hacemos \emph{implícitos} los nombres de los ficheros dando el |
jerojasro@540 | 50 nombre de un directorio, Mercurial efectúa el paso extra de imprimir |
igor@359 | 51 el nombre de cada fichero con el que va a hacer algo. Esto para |
igor@345 | 52 aclarar lo que está sucediendo, y reducir en lo posible una sorpresa |
igor@345 | 53 silenciosa pero fatal. Este comportamiento es común a la mayoría de |
igor@345 | 54 órdenes en Mercurial. |
igor@345 | 55 |
jerojasro@536 | 56 \subsection{Nota al margen: Mercurial trata ficheros, no directorios} |
igor@345 | 57 |
igor@345 | 58 Mercurial no da seguimiento a la información de los directorios. En |
igor@359 | 59 lugar de eso tiene en cuenta las rutas de los ficheros. Antes de |
igor@359 | 60 crear un fichero, primero crea todos los directorios que hagan falta |
jerojasro@540 | 61 para completar la ruta del mismo. Después de borrar un fichero, |
igor@345 | 62 borra todos los directorios vacíos que estuvieran en la ruta del |
igor@359 | 63 fichero borrado. Suena como una diferencia trivial, pero tiene una |
igor@345 | 64 consecuencia práctica menor: no es posible representar un directorio |
igor@345 | 65 completamente vacío en Mercurial. |
igor@345 | 66 |
jerojasro@536 | 67 Los directorios vacíos rara vez son útiles, y hay soluciones |
jerojasro@536 | 68 alternativas no intrusivas que usted puede emplear para obtener el efecto |
igor@345 | 69 apropiado. Los desarrolladores de Mercurial pensaron que la |
igor@345 | 70 complejidad necesaria para administrar directorios vacíos no valía la |
igor@345 | 71 pena frente al beneficio limitado que esta característica podría traer. |
igor@345 | 72 |
igor@345 | 73 Si necesita un directorio vacío en su repositorio, hay algunas formas |
igor@345 | 74 de lograrlo. Una es crear un directorio, después hacer \hgcmd{add} a |
jerojasro@536 | 75 un fichero ``oculto'' dentro de ese directorio. En sistemas tipo |
igor@359 | 76 Unix, cualquier fichero cuyo nombre comience con un punto |
jerojasro@536 | 77 (``\texttt{.}'') es tratado como oculto por la mayoría de |
jerojasro@536 | 78 comandos y herramientas GUI. Esta aproximación se ilustra en la figura~\ref{ex:daily:hidden}. |
igor@345 | 79 |
igor@345 | 80 \begin{figure}[ht] |
igor@345 | 81 \interaction{daily.files.hidden} |
jerojasro@536 | 82 \caption{Simular un directorio vacío con un fichero oculto} |
igor@345 | 83 \label{ex:daily:hidden} |
igor@345 | 84 \end{figure} |
igor@345 | 85 |
jerojasro@536 | 86 Otra forma de abordar la necesidad de un directorio vacío es |
jerojasro@536 | 87 simplemente crear uno en sus guiones de construcción antes de que lo |
jerojasro@536 | 88 necesiten. |
igor@345 | 89 |
igor@359 | 90 \section{Cómo dejar de hacer seguimiento a un fichero} |
igor@359 | 91 |
igor@359 | 92 Si decide que un fichero no pertenece a su repositorio, use la orden |
igor@359 | 93 \hgcmd{remove}; se borrará el fichero y le indicará a Mercurial que |
igor@359 | 94 deje de hacerle seguimiento. Los ficheros eliminados se representan |
igor@353 | 95 con ``\texttt{R}'' al usar \hgcmd{status}. |
igor@345 | 96 \interaction{daily.files.remove} |
igor@345 | 97 |
igor@359 | 98 Después de hacer \hgcmd{remove} a un fichero, Mercurial dejará de |
igor@359 | 99 hacer seguimiento al mismo, incluso si recrea el fichero con el mismo |
igor@359 | 100 nombre en su directorio de trabajo. Si decide recrear un fichero con |
igor@353 | 101 el mismo nombre y desea que Mercurial le haga seguimiento, basta con |
igor@359 | 102 hacerle \hgcmd{add}. Mercurial sabrá que el fichero recientemente |
igor@359 | 103 adicionado no está relacionado con el fichero anterior que tenía el |
igor@353 | 104 mismo nombre. |
igor@353 | 105 |
jerojasro@516 | 106 \subsection{Al eliminar un fichero no se afecta su historial} |
igor@359 | 107 |
jerojasro@536 | 108 Es preciso tener en cuenta que eliminar un fichero tiene sólo dos |
jerojasro@536 | 109 efectos. |
igor@345 | 110 \begin{itemize} |
igor@353 | 111 \item Se elimina la versión actual del fichero del directorio de |
igor@353 | 112 trabajo. |
igor@353 | 113 \item Mercurial deja de hacer seguimiento a los cambios del fichero |
igor@353 | 114 desde la próxima consignación. |
igor@345 | 115 \end{itemize} |
jerojasro@516 | 116 Al eliminar un fichero \emph{no} se altera de ninguna manera el |
jerojasro@516 | 117 \emph{historial} del mismo. |
igor@353 | 118 |
igor@353 | 119 Si actualiza su directorio de trabajo a un conjunto de cambios en el |
jerojasro@540 | 120 cual el fichero que eliminó aún era tenido en cuenta, éste reaparecerá en |
igor@353 | 121 el directorio de trabajo, con los contenidos que este tenía cuando se |
igor@353 | 122 consignó tal conjunto de cambios. Si usted actualiza el directorio de |
igor@359 | 123 trabajo a un conjunto de cambios posterior en el cual el fichero había |
igor@353 | 124 sido eliminado, Mercurial lo eliminará de nuevo del directorio de |
igor@353 | 125 trabajo. |
igor@345 | 126 |
igor@359 | 127 \subsection{Ficheros perdidos} |
igor@359 | 128 |
igor@359 | 129 Mercurial considera como \emph{perdido} un fichero que usted borró, |
igor@359 | 130 pero para el que no se usó \hgcmd{remove}. Los ficheros perdidos se |
igor@353 | 131 representan con ``\texttt{!}'' al visualizar \hgcmd{status}. |
igor@359 | 132 Las órdenes de Mercurial generalmente no harán nada con los ficheros |
igor@353 | 133 perdidos. |
igor@345 | 134 \interaction{daily.files.missing} |
igor@345 | 135 |
igor@359 | 136 Si su repositorio contiene un fichero que \hgcmd{status} reporta como |
igor@353 | 137 perdido, y desea que el mismo se vaya, se puede usar |
igor@353 | 138 \hgcmdargs{remove}{\hgopt{remove}{--after}} posteriormente para |
igor@359 | 139 indicarle a Mercurial que usted deseaba borrar tal fichero. |
igor@345 | 140 \interaction{daily.files.remove-after} |
igor@345 | 141 |
igor@353 | 142 Por otro lado, si borró un fichero perdido por accidente, puede usar |
igor@353 | 143 \hgcmdargs{revert}{\emph{nombre de fichero}} para recuperar el |
jerojasro@536 | 144 fichero. Reaparecerá, sin modificaciones. |
igor@345 | 145 \interaction{daily.files.recover-missing} |
igor@345 | 146 |
igor@353 | 147 \subsection{Nota al margen: ¿Por qué decirle explícitamente a Mercurial |
igor@359 | 148 que elimine un fichero?} |
igor@353 | 149 |
igor@353 | 150 Es posible que se haya preguntado por qué Mercurial exige que usted le |
igor@359 | 151 indique explícitamente que está borrando un fichero. Al principio del |
igor@359 | 152 desarrollo de Mercurial, este permitía que usted borrara el fichero |
jerojasro@540 | 153 sin más; Mercurial se daría cuenta de la ausencia del fichero |
jerojasro@540 | 154 automáticamente después de la ejecución de \hgcmd{commit}, y dejaría de |
igor@359 | 155 hacer seguimiento al fichero. En la práctica, resultaba muy sencillo |
igor@359 | 156 borrar un fichero accidentalmente sin darse cuenta. |
igor@359 | 157 |
igor@359 | 158 \subsection{Atajo útil---agregar y eliminar ficheros en un solo paso} |
igor@353 | 159 |
igor@353 | 160 Mercurial ofrece una orden combinada, \hgcmd{addremove}, que agrega |
igor@359 | 161 los ficheros que no tienen seguimiento y marca los ficheros faltantes |
igor@353 | 162 como eliminados. |
igor@345 | 163 \interaction{daily.files.addremove} |
jerojasro@540 | 164 La orden \hgcmd{commit} se puede usar con la opción \hgopt{commit}{-A} |
jerojasro@538 | 165 que aplica el mismo agregar-eliminar, seguido inmediatamente de una |
igor@353 | 166 consignación. |
igor@345 | 167 \interaction{daily.files.commit-addremove} |
igor@345 | 168 |
igor@359 | 169 \section{Copiar ficheros} |
igor@359 | 170 |
jerojasro@540 | 171 Mercurial ofrece la orden \hgcmd{copy} para hacer una copia nueva de |
jerojasro@369 | 172 un fichero. Cuando se copia un fichero con esta orden, Mercurial |
igor@378 | 173 lleva un registro indicando que el nuevo fichero es una copia del |
jerojasro@538 | 174 fichero original. Los ficheros copiados se tratan de forma especial cuando |
igor@359 | 175 usted hace una fusión con el trabajo de alguien más. |
igor@359 | 176 |
igor@378 | 177 \subsection{Resultados de copiar un fichero durante una fusión} |
igor@359 | 178 |
jerojasro@421 | 179 Durante una fusión los cambios ``siguen'' una copia. Para ilustrar |
igor@359 | 180 lo que esto significa, haremos un ejemplo. Comenzaremos con el mini |
igor@378 | 181 repositorio usual que contiene un solo fichero |
igor@345 | 182 \interaction{daily.copy.init} |
jerojasro@538 | 183 Debemos hacer algo de trabajo en paralelo, de forma que tengamos algo para |
igor@359 | 184 fusionar. Aquí clonamos el repositorio. |
igor@345 | 185 \interaction{daily.copy.clone} |
jerojasro@538 | 186 De vuelta en el repositorio inicial, usemos la orden \hgcmd{copy} para hacer |
igor@378 | 187 una copia del primer fichero que creamos. |
igor@345 | 188 \interaction{daily.copy.copy} |
igor@345 | 189 |
igor@378 | 190 Si vemos la salida de la orden \hgcmd{status}, el fichero copiado luce |
jerojasro@538 | 191 tal como un fichero que se ha añadido normalmente. |
igor@345 | 192 \interaction{daily.copy.status} |
jerojasro@538 | 193 Pero si usamos la opción \hgopt{status}{-C} de la orden |
jerojasro@538 | 194 \hgcmd{status}, se imprimirá otra línea: el fichero \emph{desde} el |
jerojasro@538 | 195 cual fue copiado nuestro fichero recién añadido. |
igor@345 | 196 \interaction{daily.copy.status-copy} |
igor@345 | 197 |
igor@359 | 198 Ahora, en el repositorio que clonamos, hagamos un cambio en |
igor@378 | 199 paralelo. Adicionaremos una línea de contenido al fichero original que |
igor@359 | 200 creamos. |
igor@345 | 201 \interaction{daily.copy.other} |
igor@359 | 202 Hemos modificado el fichero \filename{file} en este |
igor@359 | 203 repositorio. Cuando jalemos los cambios del primer repositorio y |
igor@359 | 204 fusionemos las dos cabezas, Mercurial propagará los cambios que hemos |
igor@359 | 205 hecho localmente en \filename{file} a su copia, \filename{new-file}. |
igor@345 | 206 \interaction{daily.copy.merge} |
igor@345 | 207 |
igor@359 | 208 \subsection{¿Por qué los cambios se reflejan en las copias?} |
igor@345 | 209 \label{sec:daily:why-copy} |
igor@345 | 210 |
igor@359 | 211 Este comportamiento de cambios en ficheros que se propagan a las |
igor@359 | 212 copias de los ficheros parecería esotérico, pero en la mayoría de |
igor@359 | 213 casos es absolutamente deseable. |
igor@359 | 214 Es indispensable recordar que esta propagación \emph{solamente} sucede |
igor@378 | 215 cuando fusionamos. Por lo tanto si sobre un fichero se usa |
igor@359 | 216 \hgcmd{copy}, y se modifica el fichero original durante el curso |
igor@359 | 217 normal de su trabajo, nada pasará. |
igor@359 | 218 |
igor@359 | 219 Lo segundo a tener en cuenta es que las modificaciones solamente se |
igor@359 | 220 propagarán en las copias únicamente si los repositorios de los cuales |
igor@359 | 221 está jalando los cambios \emph{no saben} de la copia. |
igor@359 | 222 |
igor@359 | 223 Explicaremos a continuación la razón de este comportamiento de |
igor@359 | 224 Mercurial. Digamos que yo he aplicado un arreglo de un fallo importante a un |
igor@378 | 225 fichero fuente y consigné los cambios. Por otro lado, usted decidió hacer |
igor@359 | 226 \hgcmd{copy} sobre el fichero en su repositorio, sin saber acerca del |
igor@359 | 227 fallo o sin ver el arreglo, y ha comenzado a trabajar sobre su copia |
igor@378 | 228 del fichero. |
igor@359 | 229 |
igor@359 | 230 Si jala y fusiona mis cambios y Mercurial \emph{no hubiera} propagado |
igor@359 | 231 los cambios en las copias, su fichero fuente tendría el fallo, a menos |
igor@359 | 232 que usted haya recordado propagar el arreglo del fallo a mano, el |
igor@378 | 233 mismo \emph{permanecería} en su copia del fichero. |
igor@359 | 234 |
igor@359 | 235 Mercurial previene esta clase de problemas, gracias a la propagación |
igor@359 | 236 automática del cambio que arregló el fallo del fichero original. Hasta |
igor@359 | 237 donde sé, Mercurial es el \emph{único} sistema de control de |
igor@359 | 238 revisiones que propaga los cambios en las copias de esta forma. |
igor@359 | 239 |
igor@359 | 240 Cuando su historial de cambios tiene un registro de la copia y la |
igor@359 | 241 subsecuente fusión, usualmente no es necesario propagar los cambios el |
jerojasro@535 | 242 fichero original a las copias del mismo, y por esta razón Mercurial |
igor@359 | 243 propaga únicamente los cambios en las copias hasta este punto y no más |
igor@359 | 244 allá. |
igor@359 | 245 |
igor@359 | 246 |
igor@359 | 247 \subsection{Cómo hacer que los cambios \emph{no} sigan a la copia?} |
igor@359 | 248 |
igor@359 | 249 Si por algún motivo usted decide que esta característica de |
jerojasro@538 | 250 propagación automática de cambios en las copias no es para usted, |
jerojasro@538 | 251 simplemente use |
jerojasro@538 | 252 la orden usual de su sistema para copiar ficheros (en sistemas tipo |
jerojasro@538 | 253 Unix, es \command{cp}), y posteriormente use \hgcmd{add} sobre la nueva |
igor@359 | 254 copia hecha a mano. Antes de hacerlo, de todas maneras, relea la |
igor@359 | 255 sección~\ref{sec:daily:why-copy}, y tome una decisión asegurándose que |
igor@359 | 256 este comportamiento no es el apropiado para su caso específico. |
igor@359 | 257 |
igor@359 | 258 \subsection{Comportamiento de la orden \hgcmd{copy}} |
igor@359 | 259 |
igor@359 | 260 Cuando usa la orden \hgcmd{copy}, Mercurial hace una copia de cada |
jerojasro@538 | 261 fichero fuente tal como se encuentra en el directorio actual. Esto |
jerojasro@538 | 262 significa que si usted hace |
igor@359 | 263 modificaciones a un fichero, y le aplica \hgcmd{copy} sin haber |
igor@359 | 264 consignado primero los cambios, la nueva copia contendrá también las |
igor@359 | 265 modificaciones que haya hecho hasta ese punto. (Este comportamiento me |
igor@359 | 266 parece poco intuitivo, y por tal motivo lo menciono.) |
igor@359 | 267 |
jerojasro@535 | 268 La orden \hgcmd{copy} actúa de forma parecida a la orden \command{cp} |
jerojasro@520 | 269 de Unix (puede usar el alias \hgcmd{cp} si le es más cómodo). El |
igor@359 | 270 último argumento es el \emph{destino}, y todos los argumentos previos |
igor@359 | 271 son las \emph{fuentes}. Si solamente indica un fichero como la |
igor@359 | 272 fuente, y el destino no existe, se crea un fichero nuevo con ese nombre. |
igor@345 | 273 \interaction{daily.copy.simple} |
jerojasro@538 | 274 Si el destino es un directorio, Mercurial copia las fuentes en éste. |
igor@345 | 275 \interaction{daily.copy.dir-dest} |
igor@359 | 276 La copia de un directorio es recursiva, y preserva la estructura del |
igor@359 | 277 directorio fuente. |
igor@345 | 278 \interaction{daily.copy.dir-src} |
igor@359 | 279 Si tanto la fuente como el destino son directorios, la estructura de |
igor@359 | 280 la fuente se recrea en el directorio destino. |
igor@345 | 281 \interaction{daily.copy.dir-src-dest} |
igor@345 | 282 |
jerojasro@538 | 283 De la misma forma que la orden \hgcmd{rename}, si copia un fichero |
igor@359 | 284 manualmente y desea que Mercurial sepa que ha copiado un fichero, |
igor@359 | 285 basta con aplicar la opción \hgopt{copy}{--after} a la orden |
igor@359 | 286 \hgcmd{copy}. |
igor@345 | 287 \interaction{daily.copy.after} |
igor@345 | 288 |
igor@373 | 289 \section{Renombrar ficheros} |
igor@373 | 290 |
igor@373 | 291 La necesidad de renombrar un fichero es más común que hacer una copia |
jerojasro@538 | 292 del mismo. La razón por la cual discutí la orden \hgcmd{copy} antes |
igor@373 | 293 de hablar acerca de cambiar el nombre de los ficheros, es que |
igor@378 | 294 Mercurial trata el renombrar un fichero de la misma forma que una |
igor@373 | 295 copia. Por lo tanto, saber lo que hace Mercurial cuando usted copia |
jerojasro@538 | 296 un fichero le indica qué esperar cuando renombra un fichero. |
igor@373 | 297 |
igor@373 | 298 Cuando usa la orden \hgcmd{rename}, Mercurial hace una copia de cada |
igor@378 | 299 fichero fuente, lo borra y lo marca como fichero eliminado. |
igor@345 | 300 \interaction{daily.rename.rename} |
igor@373 | 301 La orden \hgcmd{status} muestra la nueva copia del fichero como |
jerojasro@538 | 302 añadida y el fichero inicial de la copia, como eliminado. |
igor@345 | 303 \interaction{daily.rename.status} |
jerojasro@538 | 304 De la misma forma en que se usa la orden \hgcmd{copy}, debemos usar la |
igor@373 | 305 opción \hgopt{status}{-C} de la orden \hgcmd{status} para verificar |
igor@378 | 306 que el fichero añadido realmente comienza a ser seguido por Mercurial |
igor@373 | 307 como una copia del fichero original, ahora eliminado. |
igor@345 | 308 \interaction{daily.rename.status-copy} |
igor@345 | 309 |
igor@373 | 310 Igual que con \hgcmd{remove} y \hgcmd{copy}, puede indicársele a |
igor@373 | 311 Mercurial acerca de un renombramiento inmediato con la opción |
igor@373 | 312 \hgopt{rename}{--after}. El comportamiento de la orden |
igor@373 | 313 \hgcmd{rename} y las opciones que acepta, son similares a la orden |
igor@373 | 314 \hgcmd{copy} en casi todo. |
igor@373 | 315 |
igor@373 | 316 \subsection{Renombrar ficheros y fusionar cambios} |
igor@373 | 317 |
jerojasro@538 | 318 Dado que el renombrado de Mercurial se implementa como un |
igor@373 | 319 copiar-y-eliminar, la misma propagación de cambios ocurre cuando usted |
igor@373 | 320 fusiona después de renombrar como después de hacer una copia. |
igor@373 | 321 |
jerojasro@538 | 322 Si yo modifico un fichero y usted lo renombra a un nuevo fichero, y |
jerojasro@538 | 323 posteriormente fusionamos nuestros respectivos cambios, mi |
igor@373 | 324 modificación al fichero bajo su nombre original se propagará en el |
jerojasro@538 | 325 fichero con el nuevo nombre. (Es lo que se esperaría que ``simplemente |
jerojasro@538 | 326 funcione,'' |
jerojasro@538 | 327 pero, no todos los sistemas de control de revisiones hacen esto.) |
jerojasro@538 | 328 |
jerojasro@538 | 329 Aunque el hecho de que los cambios sigan la copia es una característica |
jerojasro@538 | 330 respecto a la cual usted puede estar de acuerdo y decir ``si, puede |
jerojasro@538 | 331 ser útil,'' debería ser claro |
jerojasro@538 | 332 que el seguimiento de cambios de un renombramiento es definitivamente |
jerojasro@538 | 333 importante. Sin esto, sería muy sencillo que los cambios se |
jerojasro@538 | 334 quedaran atrás cuando los ficheros se renombran. |
igor@373 | 335 |
igor@373 | 336 \subsection{Cambios de nombre divergentes y fusión} |
igor@373 | 337 |
igor@373 | 338 El caso de renombramiento con nombres divergentes ocurre cuando dos |
igor@373 | 339 desarrolladores comienzan con un fichero---llamémoslo |
igor@373 | 340 \filename{foo}---en sus repositorios respectivos. |
igor@345 | 341 |
igor@345 | 342 \interaction{rename.divergent.clone} |
jerojasro@541 | 343 %TODO we must either change the example's names, and these names, or |
jerojasro@541 | 344 %use the original names. as of now, we keep the old names |
jerojasro@541 | 345 Anne renombra el fichero a \filename{bar}. |
igor@345 | 346 \interaction{rename.divergent.rename.anne} |
jerojasro@541 | 347 Mientras que Bob lo renombra como \filename{quux}. |
igor@345 | 348 \interaction{rename.divergent.rename.bob} |
igor@345 | 349 |
igor@373 | 350 Veo esto como un conflicto porque cada desarrollador ha expresado |
igor@373 | 351 intenciones diferentes acerca de cómo considera debería haberse |
jerojasro@538 | 352 nombrado el fichero. |
igor@373 | 353 |
jerojasro@535 | 354 ¿Qué cree que debería pasar cuando fusionen su trabajo? |
igor@373 | 355 El comportamiento de Mercurial es que siempre preserva \emph{ambos} |
igor@373 | 356 nombres cuando fusiona los conjuntos de cambios que contienen nombres |
igor@373 | 357 divergentes. |
jerojasro@541 | 358 %TODO traducir texto interaccion |
igor@345 | 359 \interaction{rename.divergent.merge} |
igor@345 | 360 |
igor@373 | 361 Tenga en cuenta que Mercurial le advierte acerca de nombres |
igor@373 | 362 divergentes, pero deja que usted decida qué hacer con la divergencia |
igor@373 | 363 después de la fusión. |
igor@373 | 364 |
igor@373 | 365 \subsection{Cambios de nombre convergentes y fusión} |
igor@373 | 366 |
jerojasro@538 | 367 Otra clase de conflicto al cambiar el nombre de ficheros ocurre cuando dos |
igor@373 | 368 personas eligen renombrar diferentes ficheros \emph{fuente} al mismo |
igor@373 | 369 \emph{destino}. En este caso Mercurial aplica su maquinaria de fusión |
jerojasro@538 | 370 usual, y le permite a usted guiar la situación a una resolución adecuada. |
jerojasro@538 | 371 |
jerojasro@538 | 372 \subsection{Otros casos límite relacionados con renombramientos} |
igor@373 | 373 |
igor@373 | 374 Mercurial tiene un fallo de mucho tiempo en el cual no es capaz de |
igor@378 | 375 fusionar cuando por un lado hay un fichero con un nombre dado, |
igor@373 | 376 mientras que en otro hay un directorio con el mismo nombre. Esto está |
igor@373 | 377 documentado como~\bug{29}. |
igor@345 | 378 \interaction{issue29.go} |
igor@345 | 379 |
igor@373 | 380 \section{Recuperarse de equivocaciones} |
igor@373 | 381 |
igor@373 | 382 Mercurial tiene unas órdenes poderosas que le ayudarán a recuperarse |
igor@373 | 383 de equivocaciones comunes. |
igor@373 | 384 |
igor@373 | 385 La orden \hgcmd{revert} le permite deshacer cambios que haya hecho a |
jerojasro@538 | 386 su directorio de trabajo. Por ejemplo, si aplicó \hgcmd{add} a un |
igor@373 | 387 fichero por accidente, ejecute \hgcmd{revert} con el nombre del |
jerojasro@535 | 388 fichero que añadió, y en tanto que el fichero no haya sido tocado de |
igor@373 | 389 forma alguna, no será adicionado, ni seguido por Mercurial. También |
igor@373 | 390 puede usar \hgcmd{revert} para deshacerse de cambios erróneos a un |
igor@373 | 391 fichero. |
igor@373 | 392 |
igor@373 | 393 Tenga en cuenta que la orden \hgcmd{revert} se usa para cambios que no |
igor@373 | 394 han sido consignados. Cuando haya consignado un cambio, si decide que |
jerojasro@538 | 395 era un error, puede hacer algo todavía, pero sus opciones pueden estar |
igor@373 | 396 más limitadas. |
igor@373 | 397 |
igor@373 | 398 Para obtener información acerca de la orden \hgcmd{revert} y detalles |
igor@373 | 399 de cómo tratar con cambios consignados, vea el capítulo~\ref{chap:undo}. |
igor@345 | 400 |
igor@345 | 401 %%% Local Variables: |
igor@345 | 402 %%% mode: latex |
igor@345 | 403 %%% TeX-master: "00book" |
igor@345 | 404 %%% End: |