comparison es/branch.tex @ 619:bbc5db74bd77

changed many "X(" for "X (" I did this only when inside the main text

618:a529952fce96

muy buena idea tener ``demasiados'' (la cantidad variará de un
proyecto a otro), debido a que la intención es ayudarle a encontrar
revisiones. Si tiene demasiados tags, la facilidad para identificar
revisiones disminuirá rápidamente.

Por ejemplo, si su proyecto tiene etapas(milestones) frecuentes en pocos
días, es perfectamente razonable asignarle una etiqueta a cada una de
ellas. Pero si tiene un sistema de construcción automática de binarios
que asegura que cada revisión puede generarse limpiamente, estaría
introduciendo mucho ruido si se usara una etiqueta para cada generación
exitosa. Más bien, podría usar tags para generaciones fallidas (en

lee la copia de trabajo del fichero \sfilename{.hgtags}.  En cambio,
lee la versión \emph{consignada más reciente} del fichero.

Una consecuencia desafortunada de este diseño es que usted no puede
verificar que su fichero \sfilename{.hgtags} fusionado es correcto hasta
\emph{después} de haber consignado(hecho commit). Así que si se
encuentra resolviendo un conflicto en \sfilename{.hgtags} durante una
fusión, asegúrese de ejecutar la orden \hgcmd{tags} después de
consignar. Si encuentra un error en el fichero \sfilename{.hgtags}, 
reportará el lugar del error, que podrá arreglar y después
consignar. Posteriormente ejecute de nuevo la orden \hgcmd{tags} para

\interaction{branch-repo.clone}

Posteriormente, si alguien necesita trabajar en la reparación de un
fallo debería dirigirse a la liberación de versión~1.0.1 que viene en
camino, ellos clonarían el repositorio \texttt{myproject-1.0.1},
harían sus cambios y los publicarían(con push).
\interaction{branch-repo.bugfix}
Mientras tanto, el desarrollo para la siguiente versión mayor puede
continuar asilada e incólume, en el repositorio \texttt{myproject}.
\interaction{branch-repo.new}

\section{No repita trabajo: fusión entre ramas}

En muchos casos, cuando tiene un fallo para arreglar en una rama de
mantenimiento, es muy probable que el fallo esté también en la rama
principal( y posiblemente en otras ramas de mantenimiento
también). Solamente un desarrollador extraño desearía corregir el
mismo fallo muchas veces, por tanto, veremos varias alternativas con
las que Mercurial puede ayudarle a administrar tales arreglos de fallo
sin duplicar su trabajo.

La aproximación correcta en casi todas las oportunidades es aislar las
ramas en los repositorios.  Es fácil de entender gracias a su
facilidad; y es difícil cometer errores. Hay una relación uno a uno
entre las ramas y los directorios con los que está trabajando en su
sistema. Esto le permite usar emplear herramientas usuales(para los
nuevos a Mercurial) para trabajar con los ficheros dentro de su
rama/repositorio.

Si se encuentra más en la categoría ``usuario diestro'' (\emph{y} sus
colaboradores también), puede considerar otra alternativa para
administrar las ramas. He mencionador con anterioridad la distinción a
nivel humano entre las ramas estilo ``cuadro pequeño'' y ``gran
cuadro''.  Mientras que Mercurial trabaja con muchas ramas del estilo
``cuadro pequeño'' en el repositorio todo el tiempo(por ejemplo cuando
usted jala cambios, pero antes de fusionarlos), \emph{también} puede
trabajar con varias ramas del ``cuadro grande''.

El truco para trabajar de esta forma en Mercurial se logra gracias a
que puede asignar un \emph{nombre} persistente a una rama.  Siempre

619:bbc5db74bd77

muy buena idea tener ``demasiados'' (la cantidad variará de un
proyecto a otro), debido a que la intención es ayudarle a encontrar
revisiones. Si tiene demasiados tags, la facilidad para identificar
revisiones disminuirá rápidamente.

Por ejemplo, si su proyecto tiene etapas (milestones) frecuentes en pocos
días, es perfectamente razonable asignarle una etiqueta a cada una de
ellas. Pero si tiene un sistema de construcción automática de binarios
que asegura que cada revisión puede generarse limpiamente, estaría
introduciendo mucho ruido si se usara una etiqueta para cada generación
exitosa. Más bien, podría usar tags para generaciones fallidas (en

lee la copia de trabajo del fichero \sfilename{.hgtags}.  En cambio,
lee la versión \emph{consignada más reciente} del fichero.

Una consecuencia desafortunada de este diseño es que usted no puede
verificar que su fichero \sfilename{.hgtags} fusionado es correcto hasta
\emph{después} de haber consignado (hecho commit). Así que si se
encuentra resolviendo un conflicto en \sfilename{.hgtags} durante una
fusión, asegúrese de ejecutar la orden \hgcmd{tags} después de
consignar. Si encuentra un error en el fichero \sfilename{.hgtags}, 
reportará el lugar del error, que podrá arreglar y después
consignar. Posteriormente ejecute de nuevo la orden \hgcmd{tags} para

\interaction{branch-repo.clone}

Posteriormente, si alguien necesita trabajar en la reparación de un
fallo debería dirigirse a la liberación de versión~1.0.1 que viene en
camino, ellos clonarían el repositorio \texttt{myproject-1.0.1},
harían sus cambios y los publicarían (con push).
\interaction{branch-repo.bugfix}
Mientras tanto, el desarrollo para la siguiente versión mayor puede
continuar asilada e incólume, en el repositorio \texttt{myproject}.
\interaction{branch-repo.new}

\section{No repita trabajo: fusión entre ramas}

En muchos casos, cuando tiene un fallo para arreglar en una rama de
mantenimiento, es muy probable que el fallo esté también en la rama
principal ( y posiblemente en otras ramas de mantenimiento
también). Solamente un desarrollador extraño desearía corregir el
mismo fallo muchas veces, por tanto, veremos varias alternativas con
las que Mercurial puede ayudarle a administrar tales arreglos de fallo
sin duplicar su trabajo.

La aproximación correcta en casi todas las oportunidades es aislar las
ramas en los repositorios.  Es fácil de entender gracias a su
facilidad; y es difícil cometer errores. Hay una relación uno a uno
entre las ramas y los directorios con los que está trabajando en su
sistema. Esto le permite usar emplear herramientas usuales (para los
nuevos a Mercurial) para trabajar con los ficheros dentro de su
rama/repositorio.

Si se encuentra más en la categoría ``usuario diestro'' (\emph{y} sus
colaboradores también), puede considerar otra alternativa para
administrar las ramas. He mencionador con anterioridad la distinción a
nivel humano entre las ramas estilo ``cuadro pequeño'' y ``gran
cuadro''.  Mientras que Mercurial trabaja con muchas ramas del estilo
``cuadro pequeño'' en el repositorio todo el tiempo (por ejemplo cuando
usted jala cambios, pero antes de fusionarlos), \emph{también} puede
trabajar con varias ramas del ``cuadro grande''.

El truco para trabajar de esta forma en Mercurial se logra gracias a
que puede asignar un \emph{nombre} persistente a una rama.  Siempre