1.1 --- a/es/branch.tex	Sun Jan 18 21:01:13 2009 -0500
     1.2 +++ b/es/branch.tex	Sun Jan 18 21:37:11 2009 -0500
     1.3 @@ -104,35 +104,35 @@
     1.4  mover el tag hacia la revisión correcta tan pronto como localice el
     1.5  error.
     1.6  
     1.7 -Mercurial almacena las etiquetas en un archivo controlado por revisiones en
     1.8 -su repositorio. Si ha creado etiquetas, las encontrará en un archivo
     1.9 +Mercurial almacena las etiquetas en un fichero controlado por revisiones en
    1.10 +su repositorio. Si ha creado etiquetas, las encontrará en un fichero
    1.11  llamado \sfilename{.hgtags}.  Cuando invoca la orden \hgcmd{tag},
    1.12 -Mercurial modifica este archivo, y automáticamente hace consignación del
    1.13 +Mercurial modifica este fichero, y automáticamente hace consignación del
    1.14  cambio al mismo.  Esto significa que cada vez que ejecuta \hgcmd{tag},
    1.15  verá el conjunto de cambios correspondiente en la salida de \hgcmd{log}.
    1.16  \interaction{tag.tip}
    1.17  
    1.18  \subsection{Manejo de conflictos entre etiquetas durante una fusión}
    1.19  
    1.20 -Es usual no tener que preocuparse por el archivo \sfilename{.hgtags},
    1.21 +Es usual no tener que preocuparse por el fichero \sfilename{.hgtags},
    1.22  pero aveces hace su aparición durante una fusión. El formato del
    1.23 -archivo es sencillo: Consiste de una serie de líneas. Cada línea
    1.24 +fichero es sencillo: Consiste de una serie de líneas. Cada línea
    1.25  comienza con un hash de Conjunto de Cambios, seguido por un espacio,
    1.26  seguido por el nombre de un tag.
    1.27  
    1.28 -Si está resolviendo un conflicto en el archivo \sfilename{.hgtags}
    1.29 +Si está resolviendo un conflicto en el fichero \sfilename{.hgtags}
    1.30  durante una fusión, hay un detalle para tener en cuenta al modificar
    1.31 -el archivo \sfilename{.hgtags}:
    1.32 +el fichero \sfilename{.hgtags}:
    1.33  cuando Mercurial parsea las etiquetas en el repositorio \emph{nunca}
    1.34 -lee la copia de trabajo del archivo \sfilename{.hgtags}.  En cambio,
    1.35 -lee la versión \emph{consignada más reciente} del archivo.
    1.36 +lee la copia de trabajo del fichero \sfilename{.hgtags}.  En cambio,
    1.37 +lee la versión \emph{consignada más reciente} del fichero.
    1.38  
    1.39  Una consecuencia desafortunada de este diseño es que usted no puede
    1.40 -verificar que su archivo \sfilename{.hgtags} fusionado es correcto hasta
    1.41 +verificar que su fichero \sfilename{.hgtags} fusionado es correcto hasta
    1.42  \emph{después} de haber consignado(hecho commit). Así que si se
    1.43  encuentra resolviendo un conflicto en \sfilename{.hgtags} durante una
    1.44  fusión, asegúrese de ejecutar la orden \hgcmd{tags} después de
    1.45 -consignar. Si encuentra un error en el archivo \sfilename{.hgtags}, 
    1.46 +consignar. Si encuentra un error en el fichero \sfilename{.hgtags}, 
    1.47  reportará el lugar del error, que podrá arreglar y después
    1.48  consignar. Posteriormente ejecute de nuevo la orden \hgcmd{tags} para
    1.49  asegurar que su arreglo fue correctamente aplicado.
    1.50 @@ -142,24 +142,24 @@
    1.51  Puede haber notado que la orden \hgcmd{clone} tiene la opción
    1.52  \hgopt{clone}{-r} que le permite clonar una copia exacta del
    1.53  repositorio hasta un conjunto de cambios específico. El nuevo clon no
    1.54 -tendrá historia posterior a la revisión que usted haya
    1.55 +tendrá historial posterior a la revisión que usted haya
    1.56  especificado. Esta forma de interactuar puede sorprender a los
    1.57  desprevenidos.
    1.58  
    1.59 -Recuerde que un tag se almacena como una revisión al archivo
    1.60 +Recuerde que un tag se almacena como una revisión al fichero
    1.61  \sfilename{.hgtags}, consecuente con esto, cuando crea un tag, el
    1.62  conjunto de cambios en el cual este se almacena necesariamente se
    1.63  refiere a un conjunto de cambios anterior. Cuando ejecuta
    1.64  \hgcmdargs{clone}{-r foo} para clonar un repositorio hasta el tag
    1.65 -\texttt{foo}, el nuevo clon \emph{no contendrá la historia que creo
    1.66 +\texttt{foo}, el nuevo clon \emph{no contendrá el historial que creo
    1.67  el tag} que usó para clonar el repositorio. El resultado es que tendrá
    1.68 -exactamente el subconjunto correcto de la historia del proyecto en el
    1.69 +exactamente el subconjunto correcto de el historial del proyecto en el
    1.70  nuevo repositorio, pero, \emph{no} el tag que podría haber esperado.
    1.71  
    1.72  \subsection{Cuando las etiquetas permanentes son demasiado}
    1.73  
    1.74  Dado que las etiquetas de Mercurial están controladas por revisiones y se
    1.75 -llevan en la historia del proyecto, todas las personas involucradas
    1.76 +llevan en el historial del proyecto, todas las personas involucradas
    1.77  verán las etiquetas que usted haya creado. El hecho de dar nombres a las
    1.78  revisiones tiene usos más allá que simplemente hacer notar que la
    1.79  revisión \texttt{4237e45506ee} es realmente \texttt{v2.0.2}.  Si está
    1.80 @@ -168,7 +168,7 @@
    1.81  
    1.82  Para estos casos, lo que posiblemente desearía serían tags
    1.83  \emph{locales}. Puede crear un tag local con la opción \hgopt{tag}{-l}
    1.84 -de la orden \hgcmd{tag}.  Esto guardará el tag en un archivo llamado
    1.85 +de la orden \hgcmd{tag}.  Esto guardará el tag en un fichero llamado
    1.86  \sfilename{.hg/localtags}.  A diferencia de \sfilename{.hgtags},
    1.87  \sfilename{.hg/localtags} no está controlado por revisiones.
    1.88  Cualquier tag que usted cree usando \hgopt{tag}{-l} se mantendrá
    1.89 @@ -187,7 +187,7 @@
    1.90  
    1.91  Usualmente la gente se refiere a esas direcciones
    1.92  concurrentes de desarrollo es como ``ramas''.  Aunque hemos visto que
    1.93 -en variadas ocasiones Mercurial trata a \emph{toda la historia} como
    1.94 +en variadas ocasiones Mercurial trata a \emph{toda el historial} como
    1.95  una serie de ramas y fusiones.  Realmente lo que tenemos aquí es dos
    1.96  ideas que se relacionan periféricamente, pero que en esencia comparten
    1.97  un nombre.
    1.98 @@ -246,7 +246,7 @@
    1.99  facilidad; y es difícil cometer errores. Hay una relación uno a uno
   1.100  entre las ramas y los directorios con los que está trabajando en su
   1.101  sistema. Esto le permite usar emplear herramientas usuales(para los
   1.102 -nuevos a Mercurial) para trabajar con los archivos dentro de su
   1.103 +nuevos a Mercurial) para trabajar con los ficheros dentro de su
   1.104  rama/repositorio.
   1.105  
   1.106  Si se encuentra más en la categoría ``usuario diestro'' (\emph{y} sus
   1.107 @@ -291,8 +291,8 @@
   1.108  la orden \hgcmd{branch}.  ¿Qué reportan las ordenes \hgcmd{status} y
   1.109  \hgcmd{tip} commands report?
   1.110  \interaction{branch-named.status}
   1.111 -Nada cambia en el directorio actual, y no se ha añadido nada a la
   1.112 -historia. Esto sugiere que al ejecutar la orden \hgcmd{branch} no hay
   1.113 +Nada cambia en el directorio actual, y no se ha añadido nada al
   1.114 +historial. Esto sugiere que al ejecutar la orden \hgcmd{branch} no hay
   1.115  un efecto permanente; solamente le indica a que nombre de rama usará
   1.116  la \emph{próxima} vez que consigne un conjunto de cambios.
   1.117  
   1.118 @@ -336,7 +336,7 @@
   1.119  Podemos hacer \hgcmd{update} entre los tipos de las ramas \texttt{foo}
   1.120  y \texttt{bar} sin necesidad de usar la opción \hgopt{update}{-C},
   1.121  puesto que esto solamente implica ir linealmente hacia adelante y
   1.122 -atrás en nuestra historia de cambios.
   1.123 +atrás en nuestro historial de cambios.
   1.124  \interaction{branch-named.update-switchy}
   1.125  
   1.126  Si volvemos a la rama \texttt{foo} e invocamos la orden \hgcmd{update},
   1.127 @@ -389,8 +389,8 @@
   1.128  
   1.129  En el caso más sencillo, dar un nombre a cada rama ofrece un registro
   1.130  permanente acerca de en qué conjunto de cambios se generó la rama.
   1.131 -Esto le ofrece más contexto cuando esté tratando de seguir la
   1.132 -historia de un proyecto ramificado de larga vida.
   1.133 +Esto le ofrece más contexto cuando esté tratando de seguir el
   1.134 +historial de un proyecto ramificado de larga vida.
   1.135  
   1.136  Si está trabajando con repositorios compartidos, puede configurar el gancho
   1.137  \hook{pretxnchangegroup} para que cada uno bloquee los cambios con