hgbook
changeset 532:f7a2c5959d48
further revision
author | Javier Rojas <jerojasro@devnull.li> |
---|---|
date | Sun Jan 25 14:13:45 2009 -0500 (2009-01-25) |
parents | d2b1369e58d0 |
children | 871a245975e4 |
files | es/Leame.1st es/branch.tex |
line diff
1.1 --- a/es/Leame.1st Sun Jan 25 11:40:32 2009 -0500 1.2 +++ b/es/Leame.1st Sun Jan 25 14:13:45 2009 -0500 1.3 @@ -118,7 +118,7 @@ 1.4 == Archivos en proceso de revisión == 1.5 ||'''archivo''' || '''revisor''' ||'''Estado'''||'''Inicio'''|| '''Fin''' || 1.6 || 00book.tex || Javier Rojas || 100% || 18/01/2009 || 18/01/2009 || 1.7 -|| branch.tex || Javier Rojas || 0% || 25/01/2009 || || 1.8 +|| branch.tex || Javier Rojas || 90% || 25/01/2009 || || 1.9 || preface.tex || || || || || 1.10 || daily.tex || Javier Rojas || || || || 1.11 || tour-basic.tex || || || || ||
2.1 --- a/es/branch.tex Sun Jan 25 11:40:32 2009 -0500 2.2 +++ b/es/branch.tex Sun Jan 25 14:13:45 2009 -0500 2.3 @@ -14,14 +14,14 @@ 2.4 algunos fallos. 2.5 2.6 En este capítulo, comenzaremos hablando de cómo mantener registro de 2.7 -las etapas del proyecto como las liberaciones de una 2.8 +etapas del proyecto como las liberaciones de una 2.9 versión. Continuaremos hablando del flujo de trabajo entre las 2.10 -diferentes fases de un proyecto, y como puede ayudar Mercurial a 2.11 -independizar y administrar tal trabajo. 2.12 +diferentes fases de un proyecto, y cómo puede ayudar Mercurial a 2.13 +aislar y administrar tal trabajo. 2.14 2.15 \section{Dar un nombre persistente a una revisión} 2.16 2.17 -Cuando se decide a otorgar a una revisión el nombre particular de una 2.18 +Cuando usted decide otorgar a una revisión el nombre particular de una 2.19 ``versión'', es buena idea grabar la identidad de tal revisión. 2.20 Esto le permitirá reproducir dicha versión en una fecha posterior, 2.21 para cualquiera que sea el 2.22 @@ -48,21 +48,23 @@ 2.23 \item Nueva línea (ASCII 10, ``\Verb+\n+'') 2.24 \end{itemize} 2.25 2.26 -Puede usar la orden \hgcmd{tags} para observar las etiquetas presentes en 2.27 +Puede usar la orden \hgcmd{tags} para ver las etiquetas presentes en 2.28 su repositorio. Al desplegarse, cada revisión marcada se identifica 2.29 -primero con su nombre, después el número de revisión y finalmente con 2.30 +primero con su nombre, después con el número de revisión y finalmente con 2.31 un hash único de la revisión. 2.32 \interaction{tag.tags} 2.33 -Note que \texttt{tip} aparece en la lista de \hgcmd{tags}. La etiqueta 2.34 +Note que \texttt{tip} aparece en en listado generado por \hgcmd{tags}. La etiqueta 2.35 \texttt{tip} es una etiqueta ``flotante'' especial, que identifica siempre 2.36 -la revisión más nueva en el repositorio. 2.37 +la revisión más reciente en el repositorio. 2.38 2.39 Al desplegar la orden \hgcmd{tags}, las etiquetas se listan en orden 2.40 -inverso, por número de revisión. Lo que significa usualmente que las etiquetas más recientes se listan antes que las más antiguas. También 2.41 +inverso, por número de revisión. Lo que significa usualmente que las 2.42 +etiquetas más recientes se listan antes que las más antiguas. También 2.43 significa que la etiqueta \texttt{tip} siempre aparecerá como primera 2.44 etiqueta listada al desplegar la orden \hgcmd{tags}. 2.45 2.46 -Cuando ejecuta \hgcmd{log}, se desplegará la revisión que tenga las etiquetas asociadas a ella, se imprimirán tales etiquetas. 2.47 +Cuando usted ejecuta \hgcmd{log}, si se muestra una revisión que tenga 2.48 +etiquetas asociadas a ella, se imprimirán tales etiquetas. 2.49 \interaction{tag.log} 2.50 2.51 Siempre que requiera indicar un~ID de revisión a una orden de 2.52 @@ -73,12 +75,12 @@ 2.53 2.54 No hay límites en la cantidad de etiquetas por repositorio, o la cantidad 2.55 de etiquetas que una misma revisión pueda tener. Siendo prácticos, no es 2.56 -muy buena idea tener ``demasiados'' (la cantidad variará de un 2.57 +muy buena idea tener ``demasiadas'' (la cantidad variará de un 2.58 proyecto a otro), debido a que la intención es ayudarle a encontrar 2.59 -revisiones. Si tiene demasiados tags, la facilidad para identificar 2.60 -revisiones disminuirá rápidamente. 2.61 - 2.62 -Por ejemplo, si su proyecto tiene etapas (milestones) frecuentes en pocos 2.63 +revisiones. Si tiene demasiadas etiquetas, la facilidad de usarlas 2.64 +para identificar revisiones disminuirá rápidamente. 2.65 + 2.66 +Por ejemplo, si su proyecto tiene etapas (milestones) frecuentes, de pocos 2.67 días, es perfectamente razonable asignarle una etiqueta a cada una de 2.68 ellas. Pero si tiene un sistema de construcción automática de binarios 2.69 que asegura que cada revisión puede generarse limpiamente, estaría 2.70 @@ -88,34 +90,34 @@ 2.71 llevar cuenta de la posibilidad de generación de binarios. 2.72 2.73 2.74 -Si desea eliminar una etiqueta que no desea, use 2.75 +Si quiere eliminar una etiqueta que no desea, use 2.76 \hgcmdargs{tag}{--remove}. 2.77 \interaction{tag.remove} 2.78 -También puede modificar una etiqueta en cualquier momento para que 2.79 -identifique una revisión distinta, basta con aplicar una nueva orden 2.80 +También puede modificar una etiqueta en cualquier momento, para que 2.81 +identifique una revisión distinta, simplemente usando una nueva orden 2.82 \hgcmd{tag}. Deberá usar la opción \hgopt{tag}{-f} para indicarle a 2.83 -Mercurial que desea actualizar la etiqueta \emph{en serio}. 2.84 +Mercurial que \emph{realmente} desea actualizar la etiqueta. 2.85 \interaction{tag.replace} 2.86 De todas maneras habrá un registro permanente de la antigua identidad 2.87 -del tag, pero Mercurial no la usará. Por lo tanto no hay castigo al 2.88 -marcar con una etiqueta una revisión incorrecta; lo único que debe hacer es 2.89 -mover la etiqueta hacia la revisión correcta tan pronto como localice el 2.90 -error. 2.91 +de la etiqueta, pero Mercurial no la usará. Por lo tanto no hay 2.92 +problema al marcar con una etiqueta una revisión incorrecta; lo único 2.93 +que debe hacer es mover la etiqueta hacia la revisión correcta tan 2.94 +pronto como localice el error. 2.95 2.96 Mercurial almacena las etiquetas en un fichero controlado por revisiones en 2.97 su repositorio. Si ha creado etiquetas, las encontrará en un fichero 2.98 llamado \sfilename{.hgtags}. Cuando invoca la orden \hgcmd{tag}, 2.99 -Mercurial modifica este fichero, y automáticamente hace consignación del 2.100 +Mercurial modifica este fichero, y automáticamente hace la consignación del 2.101 cambio al mismo. Esto significa que cada vez que ejecuta \hgcmd{tag}, 2.102 -verá el conjunto de cambios correspondiente en la salida de \hgcmd{log}. 2.103 +verá un conjunto de cambios correspondiente en la salida de \hgcmd{log}. 2.104 \interaction{tag.tip} 2.105 2.106 \subsection{Manejo de conflictos entre etiquetas durante una fusión} 2.107 2.108 -Es usual no tener que preocuparse por el fichero \sfilename{.hgtags}, 2.109 -pero aveces hace su aparición durante una fusión. El formato del 2.110 +Usualmente no tendrá que preocuparse por el fichero \sfilename{.hgtags}, 2.111 +pero a veces hace su aparición durante una fusión. El formato del 2.112 fichero es sencillo: Consiste de una serie de líneas. Cada línea 2.113 -comienza con un hash de Conjunto de Cambios, seguido por un espacio, 2.114 +comienza con un hash de conjunto de cambios, seguido por un espacio, 2.115 seguido por el nombre de una etiqueta. 2.116 2.117 Si está resolviendo un conflicto en el fichero \sfilename{.hgtags} 2.118 @@ -126,27 +128,27 @@ 2.119 lee la versión \emph{consignada más reciente} del fichero. 2.120 2.121 Una consecuencia desafortunada de este diseño es que usted no puede 2.122 -verificar que su fichero \sfilename{.hgtags} fusionado es correcto hasta 2.123 +verificar que su fichero \sfilename{.hgtags} fusionado sea correcto hasta 2.124 \emph{después} de haber consignado un cambio. Así que si se 2.125 encuentra resolviendo un conflicto en \sfilename{.hgtags} durante una 2.126 fusión, asegúrese de ejecutar la orden \hgcmd{tags} después de 2.127 consignar. Si encuentra un error en el fichero \sfilename{.hgtags}, 2.128 -reportará el lugar del error, que podrá arreglar y después 2.129 +la orden reportará el lugar del error, que podrá arreglar y después 2.130 consignar. Posteriormente ejecute de nuevo la orden \hgcmd{tags} para 2.131 -asegurar que su arreglo fue correctamente aplicado. 2.132 - 2.133 -\subsection{Tags y clonado} 2.134 +asegurarse de que su arreglo fue aplicado correctamente . 2.135 + 2.136 +\subsection{Etiquetas y clonado} 2.137 2.138 Puede haber notado que la orden \hgcmd{clone} tiene la opción 2.139 \hgopt{clone}{-r} que le permite clonar una copia exacta del 2.140 repositorio hasta un conjunto de cambios específico. El nuevo clon no 2.141 tendrá historial posterior a la revisión que usted haya 2.142 -especificado. Esta forma de interactuar puede sorprender a los 2.143 -desprevenidos. 2.144 +especificado. Esto tiene una interacción con etiquetas que puede 2.145 +sorprender a los desprevenidos. 2.146 2.147 Recuerde que una etiqueta se almacena como una revisión al fichero 2.148 -\sfilename{.hgtags}, consecuente con esto, cuando crea una etiqueta, el 2.149 -conjunto de cambios en el cual este se almacena necesariamente se 2.150 +\sfilename{.hgtags}, así que cuando usted crea una etiqueta, el 2.151 +conjunto de cambios en el cual ésta se almacena necesariamente se 2.152 refiere a un conjunto de cambios anterior. Cuando ejecuta 2.153 \hgcmdargs{clone}{-r foo} para clonar un repositorio hasta la etiqueta 2.154 \texttt{foo}, el nuevo clon \emph{no contendrá el historial que creo 2.155 @@ -164,13 +166,13 @@ 2.156 tratando de encontrar un fallo sutil, posiblemente desearía colocar una 2.157 etiqueta recordándole algo como ``Ana vio los síntomas con esta revisión''. 2.158 2.159 -Para estos casos, lo que posiblemente desearía serían tags 2.160 +Para estos casos, lo que posiblemente desearía serían etiquetas 2.161 \emph{locales}. Puede crear una etiqueta local con la opción \hgopt{tag}{-l} 2.162 de la orden \hgcmd{tag}. Esto guardará la etiqueta en un fichero llamado 2.163 \sfilename{.hg/localtags}. A diferencia de \sfilename{.hgtags}, 2.164 \sfilename{.hg/localtags} no está controlado por revisiones. 2.165 -Cualquier tag que usted cree usando \hgopt{tag}{-l} se mantendrá 2.166 -localmente en el repositorio en el que esté trabajando en ese momento. 2.167 +Cualquier etiqueta que usted cree usando \hgopt{tag}{-l} se mantendrá 2.168 +localmente al repositorio en el que esté trabajando en ese momento. 2.169 2.170 \section{El flujo de cambios---El gran cuadro vs. el pequeño} 2.171 2.172 @@ -178,14 +180,14 @@ 2.173 hecho de que un proyecto tiene muchas piezas concurrentes de trabajo 2.174 en desarrollo al mismo tiempo. 2.175 2.176 -Puede haber prisa por una nueva versión ``principal''; Un nueva 2.177 +Puede haber prisa por una nueva versión ``principal''; una nueva 2.178 versión con un arreglo de fallo a la última versión; y una versión de 2.179 ``mantenimiento correctivo'' a una versión antigua que ha entrado en 2.180 modo de mantenimiento. 2.181 2.182 Usualmente la gente se refiere a esas direcciones 2.183 -concurrentes de desarrollo es como ``ramas''. Aunque hemos visto que 2.184 -en variadas ocasiones Mercurial trata a \emph{toda el historial} como 2.185 +concurrentes de desarrollo como ``ramas''. Sin embargo, ya hemos visto que 2.186 +en varias ocasiones Mercurial trata a \emph{todo el historial} como 2.187 una serie de ramas y fusiones. Realmente lo que tenemos aquí es dos 2.188 ideas que se relacionan periféricamente, pero que en esencia comparten 2.189 un nombre. 2.190 @@ -194,7 +196,7 @@ 2.191 evolución del proyecto; la gente les da nombres y hablan acerca de 2.192 ellas en sus conversaciones. 2.193 \item ``El cuadro pequeño'' Las ramas son artefactos de las 2.194 - actividades diarias de al desarrollar y fusionar cambios. Exponen la 2.195 + actividades diarias de desarrollar y fusionar cambios. Exponen la 2.196 narrativa de cómo se desarrolló el código. 2.197 \end{itemize} 2.198 2.199 @@ -205,19 +207,19 @@ 2.200 repositorio compartido existente ---llamémoslo 2.201 \texttt{myproject}---que alcanzó la etapa ``1.0'', puede comenzar a 2.202 prepararse para versiones de mantenimiento futuras a partir de la 2.203 -versión~1.0 marcando con una etiqueta en la revisión con la cual preparó la versión~1.0. 2.204 +versión~1.0 marcando con una etiqueta la revisión con la cual preparó la versión~1.0. 2.205 \interaction{branch-repo.tag} 2.206 Ahora puede clonar un repositorio compartido nuevo 2.207 -\texttt{myproject-1.0.1} con tal tag. 2.208 +\texttt{myproject-1.0.1} con tal etiqueta. 2.209 \interaction{branch-repo.clone} 2.210 2.211 Posteriormente, si alguien necesita trabajar en la reparación de un 2.212 fallo debería dirigirse a la liberación de versión~1.0.1 que viene en 2.213 camino, ellos clonarían el repositorio \texttt{myproject-1.0.1}, 2.214 -harían sus cambios y los publicarían (con push). 2.215 +harían sus cambios y los empujarían de vuelta. 2.216 \interaction{branch-repo.bugfix} 2.217 Mientras tanto, el desarrollo para la siguiente versión mayor puede 2.218 -continuar aislada e incólume, en el repositorio \texttt{myproject}. 2.219 +continuar aislado e incólume, en el repositorio \texttt{myproject}. 2.220 \interaction{branch-repo.new} 2.221 2.222 \section{No repita trabajo: fusión entre ramas} 2.223 @@ -233,7 +235,7 @@ 2.224 En el caso más sencillo, basta con jalar los cambios de la rama de 2.225 mantenimiento a la rama objetivo en su clon local. 2.226 \interaction{branch-repo.pull} 2.227 -A continuación deberá mezclar las cabezas de las dos ramas, y publicar 2.228 +A continuación deberá mezclar las cabezas de las dos ramas, y empujar 2.229 de nuevo a la rama principal. 2.230 \interaction{branch-repo.merge} 2.231 2.232 @@ -241,10 +243,10 @@ 2.233 2.234 La aproximación correcta en casi todas las oportunidades es aislar las 2.235 ramas en los repositorios. Es fácil de entender gracias a su 2.236 -facilidad; y es difícil cometer errores. Hay una relación uno a uno 2.237 +simplicidad; y es difícil cometer errores. Hay una relación uno a uno 2.238 entre las ramas y los directorios con los que está trabajando en su 2.239 -sistema. Esto le permite usar emplear herramientas usuales (para los 2.240 -nuevos a Mercurial) para trabajar con los ficheros dentro de su 2.241 +sistema. Esto le permite usar emplear herramientas usuales (que no son 2.242 +conscientes de Mercurial) para trabajar con los ficheros dentro de una 2.243 rama/repositorio. 2.244 2.245 Si se encuentra más en la categoría ``usuario diestro'' (\emph{y} sus 2.246 @@ -268,16 +270,16 @@ 2.247 está indicando que su consignación ocurrirá en la rama llamada 2.248 \texttt{default}. 2.249 2.250 -Use la orden \hgcmd{branches} para comenzar a trabajar con ramas 2.251 +Use la orden \hgcmd{branches} para empezar a trabajar con ramas 2.252 nombradas. Esta orden mostrará las ramas presentes en su repositorio, 2.253 -indicándole en qué conjunto de cambios está cada una. 2.254 +indicándole qué conjunto de cambios es la punta de cada una. 2.255 \interaction{branch-named.branches} 2.256 -Dado que todavía no ha creado ramas nombradas, la única que verá sería 2.257 +Dado que todavía no ha creado ramas nombradas, la única que verá será 2.258 \texttt{default}. 2.259 2.260 Para hallar cuál es la rama ``actual'', invoque la orden 2.261 \hgcmd{branch}, sin argumento alguno. Le informará en qué rama se 2.262 -encuentra el padre del conjunto actual de cambios. 2.263 +encuentra el padre del conjunto de cambios actual. 2.264 \interaction{branch-named.branch} 2.265 2.266 Para crear una nueva rama, invoque la orden \hgcmd{branch} de 2.267 @@ -287,7 +289,7 @@ 2.268 2.269 Después de crear la rama, usted podría desear ver el efecto que tuvo 2.270 la orden \hgcmd{branch}. ¿Qué reportan las ordenes \hgcmd{status} y 2.271 -\hgcmd{tip} commands report? 2.272 +\hgcmd{tip}? 2.273 \interaction{branch-named.status} 2.274 Nada cambia en el directorio actual, y no se ha añadido nada al 2.275 historial. Esto sugiere que al ejecutar la orden \hgcmd{branch} no hay 2.276 @@ -301,7 +303,7 @@ 2.277 desplieguen la misma clase de información. 2.278 \interaction{branch-named.commit} 2.279 Las órdenes del tipo \hgcmd{log} imprimirán el nombre de la rama de 2.280 -cualquier conjunto de cambios que no estén en la rama 2.281 +cualquier conjunto de cambios que no esté en la rama 2.282 \texttt{default}. Como resultado, si nunca usa ramas nombradas, nunca 2.283 verá esta información. 2.284 2.285 @@ -319,12 +321,12 @@ 2.286 Si tiene más de una rama nombrada en un repositorio, Mercurial 2.287 recordará la rama en la cual está su directorio de trabajo cuando 2.288 invoque una orden como \hgcmd{update} o \hgcmdargs{pull}{-u}. Se 2.289 -actualizará su directorio de trabajo actual al tip de esta rama, sin 2.290 -importar cuál sea el tip ``a lo largo del repositorio''. Para 2.291 +actualizará su directorio de trabajo actual a la punta de esta rama, sin 2.292 +importar cuál sea la punta ``a lo largo del repositorio''. Para 2.293 actualizar a una revisión que está en una rama con distinto nombre, 2.294 puede necesitar la opción \hgopt{update}{-C} de \hgcmd{update}. 2.295 2.296 -Este comportamiento puede ser sutil, veámoslo en acción. Primero, 2.297 +Este comportamiento puede ser sutil, así que veámoslo en acción. Primero, 2.298 recordemos en qué rama estamos trabajando, y qué ramas están en 2.299 nuestro repositorio. 2.300 \interaction{branch-named.parents} 2.301 @@ -338,7 +340,7 @@ 2.302 \interaction{branch-named.update-switchy} 2.303 2.304 Si volvemos a la rama \texttt{foo} e invocamos la orden \hgcmd{update}, 2.305 -nos mantendrá en \texttt{foo}, sin movernos al tipo de \texttt{bar}. 2.306 +nos mantendrá en \texttt{foo}, sin movernos a la punta de \texttt{bar}. 2.307 \interaction{branch-named.update-nothing} 2.308 2.309 Al consignar un cambio a la rama \texttt{foo} se introducirá una nueva