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

     2.1 --- a/es/cmdref.tex	Sun Jan 18 21:01:13 2009 -0500
     2.2 +++ b/es/cmdref.tex	Sun Jan 18 21:37:11 2009 -0500
     2.3 @@ -6,14 +6,14 @@
     2.4  \optref{add}{X}{exclude}
     2.5  \optref{add}{n}{dry-run}
     2.6  
     2.7 -\cmdref{diff}{imprime los cambios en la historia o el directorio actual}
     2.8 +\cmdref{diff}{imprime los cambios en el historial o el directorio actual}
     2.9  
    2.10  Mostrar las diferencias entre revisiones para ficheros especificados o
    2.11  directorios, con el formato unificado diff.  Si desea ver una
    2.12  descripción del formato unificado diff, ver la sección~\ref{sec:mq:patch}.
    2.13  
    2.14  De forma predeterminada, esta orden no imprime las diferencias para
    2.15 -los archivos binarios que Mercurial esté siguiendo.  Para controlar
    2.16 +los ficheros binarios que Mercurial esté siguiendo.  Para controlar
    2.17  este comportamiento, vea las opciones \hgopt{diff}{-a} y
    2.18  \hgopt{diff}{--git}.
    2.19  

     3.1 --- a/es/collab.tex	Sun Jan 18 21:01:13 2009 -0500
     3.2 +++ b/es/collab.tex	Sun Jan 18 21:37:11 2009 -0500
     3.3 @@ -13,7 +13,7 @@
     3.4  capacidades útiles.
     3.5  
     3.6  Para uso interactivo, la interfaz le permite visualizar uno o varios
     3.7 -repositorios. Puede ver la historia de un repositorio, examinar cada
     3.8 +repositorios. Puede ver el historial de un repositorio, examinar cada
     3.9  cambio(comentarios y diferencias), y ver los contenidos de cada
    3.10  directorio y fichero.
    3.11  
    3.12 @@ -49,7 +49,7 @@
    3.13  CGI, como en la sección~\ref{sec:collab:cgi}.  Publicar sobre HTTP
    3.14  satisface las necesidades de la gente que no tiene permisos de
    3.15  publicación y de aquellos que quieren usar navegadores web para
    3.16 -visualizar la historia del repositorio.
    3.17 +visualizar el historial del repositorio.
    3.18  
    3.19  \subsection{Trabajo con muchas ramas}
    3.20  
    3.21 @@ -270,7 +270,7 @@
    3.22  La orden \hgcmd{serve} \emph{no} es un servidor web de propósito
    3.23  general. Solamente puede hacer dos cosas:
    3.24  \begin{itemize}
    3.25 -\item Permitir que se pueda visualizar la historia del repositorio que
    3.26 +\item Permitir que se pueda visualizar el historial del repositorio que
    3.27    está sirviendo desde navegadores web.
    3.28  \item Hablar el protocolo de conexión de Mercurial para que puedan hacer
    3.29    \hgcmd{clone} o \hgcmd{pull} (jalar) cambios de tal repositorio.
    3.30 @@ -520,7 +520,7 @@
    3.31    este síntoma.
    3.32  \item El fichero de usuario \sfilename{authorized\_keys} puede tener
    3.33    un problema.  Si alguien distinto al usuario es dueño o puede
    3.34 -  escribir el archivo, el daemonio ssh no confiará o lo leerá.
    3.35 +  escribir el fichero, el daemonio ssh no confiará o lo leerá.
    3.36  \end{itemize}
    3.37  
    3.38  En un mundo ideal, debería poder ejecutar la siguiente orden
    3.39 @@ -785,7 +785,7 @@
    3.40  completa al repositorio que desea servir.
    3.41  
    3.42  En este punto, cuando trate de recargar la página, deberá visualizar
    3.43 -una linda vista HTML de la historia de su repositorio. Uff!
    3.44 +una linda vista HTML de el historial de su repositorio. Uff!
    3.45  
    3.46  \subsubsection{Configuración de lighttpd}
    3.47  
    3.48 @@ -879,13 +879,13 @@
    3.49  virtual \dirname{ruta/este/repo} en lugar de \dirname{este/repo}.
    3.50  
    3.51  El guión \sfilename{hgwebdir.cgi} buscará recursivamente en cada
    3.52 -directorio listado en la sección \texttt{collections} de su archivo de
    3.53 +directorio listado en la sección \texttt{collections} de su fichero de
    3.54  configuración, pero \texttt{no} hará el recorrido recursivo dentro de
    3.55  los repositorios que encuentre.
    3.56  
    3.57  El mecanismo de \texttt{collections} permite publicar fácilmente
    3.58  repositorios de una forma ``hacer y olvidar''.  Solamente requiere
    3.59 -configurar el guión CGI y el archivo de configuración una vez.
    3.60 +configurar el guión CGI y el fichero de configuración una vez.
    3.61  Después de eso puede publicar y sacar de publicación un repositorio en
    3.62  cualquier momento incluyéndolo o excluyéndolo de la jerarquía de
    3.63  directorios en la cual le haya indicado a \sfilename{hgwebdir.cgi} que
    3.64 @@ -906,10 +906,10 @@
    3.65  está en el lado derecho de cada definición, mientras que la ruta al
    3.66  repositorio está a la derecha.  Note que no tiene que haber relación
    3.67  alguna entre la ruta virtual que elija y el lugar del repositorio en
    3.68 -su sistema de archivos.
    3.69 +su sistema de ficheros.
    3.70  
    3.71  Si lo desea, puede usar los dos mecanismos \texttt{collections} y
    3.72 -\texttt{paths} simultáneamente en un sólo archivo de configuración.
    3.73 +\texttt{paths} simultáneamente en un sólo fichero de configuración.
    3.74  
    3.75  \begin{note}
    3.76    Si varios repositorios tienen la misma ruta virtual,
    3.77 @@ -935,7 +935,7 @@
    3.78  opciones de configuración para establecer. Todas ellas en la sección
    3.79  \rcsection{web}.
    3.80  \begin{itemize}
    3.81 -\item[\rcitem{web}{allow\_archive}] Determina cuáles tipos de archivos
    3.82 +\item[\rcitem{web}{allow\_archive}] Determina cuáles tipos de ficheros
    3.83    de descarga soportará Mercurial.  Si habilita esta característica,
    3.84    los usuarios de la interfaz web podrán descargar una copia de la
    3.85    revisión del repositorio que estén viendo. Para activar la
    3.86 @@ -989,7 +989,7 @@
    3.87      style = gitweb
    3.88    \end{codesample4}
    3.89  \item[\rcitem{web}{templates}] Ruta.  Directorio en el que se buscarán
    3.90 -  los archivos plantilla.  De forma predeterminada, busca en el
    3.91 +  los ficheros plantilla.  De forma predeterminada, busca en el
    3.92    directorio en el cual fue instalado.
    3.93  \end{itemize}
    3.94  Si usa \sfilename{hgwebdir.cgi}, puede añadir otras opciones de

     4.1 --- a/es/concepts.tex	Sun Jan 18 21:01:13 2009 -0500
     4.2 +++ b/es/concepts.tex	Sun Jan 18 21:37:11 2009 -0500
     4.3 @@ -563,7 +563,7 @@
     4.4  
     4.5  Mercurial usar bloqueos para asegurarse de que sólo un proceso pueda
     4.6  escribir a un repositorio al mismo tiempo (el mecanismo de bloqueo es
     4.7 -seguro incluso sobre sistemas de archivos notoriamente hostiles al
     4.8 +seguro incluso sobre sistemas de ficheros notoriamente hostiles al
     4.9  bloqueo, como NFS). Si un repositorio está bloqueado, los escritores
    4.10  esperarán un buen rato para revisar si el repositorio ya ha sido
    4.11  desbloqueado, pero si el repositorio sique bloqueado por mucho tiempo,

     5.1 --- a/es/daily.tex	Sun Jan 18 21:01:13 2009 -0500
     5.2 +++ b/es/daily.tex	Sun Jan 18 21:37:11 2009 -0500
     5.3 @@ -102,7 +102,7 @@
     5.4  adicionado no está relacionado con el fichero anterior que tenía el
     5.5  mismo nombre.
     5.6  
     5.7 -\subsection{Al eliminar un fichero no se afecta su historia}
     5.8 +\subsection{Al eliminar un fichero no se afecta su historial}
     5.9  
    5.10  Es preciso tener en cuenta que al eliminar un fichero se tiene
    5.11  dos efectos solamente.
    5.12 @@ -112,8 +112,8 @@
    5.13  \item Mercurial deja de hacer seguimiento a los cambios del fichero
    5.14    desde la próxima consignación.
    5.15  \end{itemize}
    5.16 -Al eliminar un fichero \emph{no} se altera de ninguna manera la
    5.17 -\emph{historia} del mismo.
    5.18 +Al eliminar un fichero \emph{no} se altera de ninguna manera el
    5.19 +\emph{historial} del mismo.
    5.20  
    5.21  Si actualiza su directorio de trabajo a un conjunto de cambios en el
    5.22  cual esl fichero que eliminó aún era tenido en cuenta, reaparecerá en

     6.1 --- a/es/filenames.tex	Sun Jan 18 21:01:13 2009 -0500
     6.2 +++ b/es/filenames.tex	Sun Jan 18 21:37:11 2009 -0500
     6.3 @@ -200,7 +200,7 @@
     6.4  cadena. Para buscar coincidencias en cualquier sitio dentro de una
     6.5  cadena, empiece su patrón con un ``\texttt{.*}''.
     6.6  
     6.7 -\section{Filtrado de archivos}
     6.8 +\section{Filtrado de ficheros}
     6.9  
    6.10  Mercurial no sólo le provee una variedad de formas para especificar
    6.11  ficheros; le permite limitar aún más dichos ficheros mediante el uso
    6.12 @@ -284,7 +284,7 @@
    6.13  \subsection{Detección de conflictos de mayúsculas/minúsculas}
    6.14  
    6.15  Al operar en el directorio de trabajo, Mercurial respeta la política
    6.16 -de nombrado del sistema de archivos en que se encuentre el directorio
    6.17 +de nombrado del sistema de ficheros en que se encuentre el directorio
    6.18  de trabajo. Si el sistema de ficheros conserva las diferencias entre
    6.19  mayúsculas, pero no es sensible a ellas, Mercurial tratará los nombres
    6.20  que sólo difieren en mayúsculas como uno solo y el mismo.

     7.1 --- a/es/hgext.tex	Sun Jan 18 21:01:13 2009 -0500
     7.2 +++ b/es/hgext.tex	Sun Jan 18 21:37:11 2009 -0500
     7.3 @@ -55,18 +55,18 @@
     7.4  buen desempeño, los autores de Mercurial han optimizado este código en
     7.5  la medida de lo posible.  Sin embargo, no puede obviarse el hecho de
     7.6  que cuando ejecuta \hgcmd{status}, Mercurial tendrá que hacer por lo
     7.7 -menos una costosa llamada al sistema por cada archivo administrado
     7.8 +menos una costosa llamada al sistema por cada fichero administrado
     7.9  para determinar si ha cambiado desde la última vez que se consignó.
    7.10  Para un repositorio suficientemente grande, puede tardar bastante
    7.11  tiempo.
    7.12  
    7.13  Para mostrar en números la magnitud de este efect, creé un repositorio
    7.14 -que contenía 150.000 archivos administrador.  Tardó diez segundos para
    7.15 +que contenía 150.000 ficheros administrador.  Tardó diez segundos para
    7.16  ejecutar \hgcmd{status}, a pesar de que \emph{ninguno} de los ficheros
    7.17  había sido modificado.
    7.18  
    7.19  Muchos sistemas operativos modernos contienen una facilidad de
    7.20 -notificación de archivos.  Si un programa se registra con un servicio
    7.21 +notificación de ficheros.  Si un programa se registra con un servicio
    7.22  apropiado, el sistema operativo le notificará siempre que un fichero
    7.23  de interés haya sido creado, modificado o borrado.  En sistemas Linux,
    7.24  el componente del núcleo que lo hace se llama \texttt{inotify}.

     8.1 --- a/es/intro.tex	Sun Jan 18 21:01:13 2009 -0500
     8.2 +++ b/es/intro.tex	Sun Jan 18 21:37:11 2009 -0500
     8.3 @@ -26,8 +26,7 @@
     8.4  Hay muchas razones por las cuales usted o su equipo desearía usar una
     8.5  herramienta automática de control de revisiones para un proyecto.
     8.6  \begin{itemize}
     8.7 -        %TODO historia
     8.8 -\item Llevar registro de la historia y la evolución de su proyecto, para
     8.9 +\item Llevar registro de el historial y la evolución de su proyecto, para
    8.10    evitar hacer la tarea manualmente. Por cada cambio, tendrá una
    8.11    bitácora de \emph{quién} lo hizo; \emph{por qué} se hizo;
    8.12    \emph{cuándo} se hizo; y de \emph{qué} se trataba el cambio.
    8.13 @@ -136,8 +135,7 @@
    8.14  desarrollado la versión moderna de CVS.  CVS adquirió posteriormente 
    8.15  la habilidad de operar sobre una conexión de red, dotándolo de una
    8.16  arquitectura, cliente/servidor. La arquitectura de CVS es
    8.17 -%TODO historia/historial
    8.18 -centralizada; La historia del proyecto está únicamente en el
    8.19 +centralizada; el historial del proyecto está únicamente en el
    8.20  repositorio central.  Los espacios de trabajo de los clientes
    8.21  contienen únicamente copias recientes de las versiones de los
    8.22  ficheros, y pocos metadatos para indicar dónde está el servidor. CVS
    8.23 @@ -147,9 +145,9 @@
    8.24  A comienzos de los noventa~(1990s), Sun MicroSystems desarrollo un
    8.25  temprano sistema distribuido de control de revisiones llamado
    8.26  TeamWare.
    8.27 -Un espacio de trabajo TeamWare contiene una copia completa de la
    8.28 -historia del proyecto. TeamWare no tiene la noción de repositorio
    8.29 -central. (CVS se basaba en RCS para el almacenamiento de su historia;
    8.30 +Un espacio de trabajo TeamWare contiene una copia completa de el
    8.31 +historial del proyecto. TeamWare no tiene la noción de repositorio
    8.32 +central. (CVS se basaba en RCS para el almacenamiento de su historial;
    8.33  TeamWare usaba SCCS.)
    8.34  
    8.35  A medida que avanzaba la decada de los noventa, se empezó a
    8.36 @@ -265,8 +263,7 @@
    8.37  a trabajar en él, y ese proyecto usa una herramienta de control
    8.38  distribuido de revisiones, usted es de inmediato un par con la gente que se
    8.39  considera el ``alma'' del proyecto.  Si ellos publican sus
    8.40 -%TODO historia/historial
    8.41 -repositorios, usted puede copiar inmediatamente la historia del proyecto,
    8.42 +repositorios, usted puede copiar inmediatamente el historial del proyecto,
    8.43  hacer cambios y guardar su trabajo, usando las mismas herramientas de
    8.44  la misma forma que ellos. En contraste, con una herramienta
    8.45  centralizada, usted debe usar el programa en un modo ``sólo lectura'' a
    8.46 @@ -289,10 +286,8 @@
    8.47  En algunas ocasiones los líderes de las bifurcaciones reconcilian sus
    8.48  diferencias. Con un sistema centralizado de control de revisiones, el
    8.49  proceso \emph{técnico} de reconciliarse es doloroso, y se hace de
    8.50 -%TODO historia/historial
    8.51 -forma muy manual.  Usted tiene que decidir qué historia de revisiones va a
    8.52 +forma muy manual.  Usted tiene que decidir qué historial de revisiones va a
    8.53  ``ganar'', e injertar los cambios del otro equipo en el árbol de alguna
    8.54 -%TODO historia/historial
    8.55  manera. Con esto usualmente se pierde algo o todo del historial de la
    8.56  revisión de alguna de las partes.
    8.57  
    8.58 @@ -323,11 +318,11 @@
    8.59  desean mantener control completo sobre sus proyectos, y creen que las
    8.60  herramientas centralizadas les dan tal control. En todo caso, si este
    8.61  es su parecer, y usted publica sus repositorios de CVS o Subversion, hay
    8.62 -muchas herramientas disponibles que pueden obtener la historia
    8.63 -completa (aunque sea lentamente) y recrearla en otro sitio que usted no
    8.64 +muchas herramientas disponibles que pueden obtener el historial
    8.65 +completo (aunque sea lentamente) y recrearlo en otro sitio que usted no
    8.66  controla. Siendo así un control ilusorio, puesto que está impidiendo
    8.67  la fluidez de colaboración en lugar de prevenir que alguien se sienta
    8.68 -impulsado a obtener una copia y hacer una bifurcación con su historia.
    8.69 +impulsado a obtener una copia y hacer una bifurcación con su historial.
    8.70  
    8.71  \subsection{Ventajas para proyectos comerciales}
    8.72  
    8.73 @@ -357,8 +352,8 @@
    8.74  sistema distribuido de control de versiones al resolver problemas en
    8.75  el sitio del cliente. La herramienta le permitirá generar
    8.76  construcciones a la medida, probar diferentes arreglos de forma
    8.77 -independiente y buscar de forma eficiente las fuentes de fallos en la
    8.78 -historia y regresiones en los ambientes de los clientes, todo sin
    8.79 +independiente y buscar de forma eficiente las fuentes de fallos en el
    8.80 +historial y regresiones en los ambientes de los clientes, todo sin
    8.81  necesidad de conectarse al servidor de su compañía.
    8.82  
    8.83  \section{¿Por qué elegir Mercurial?}
    8.84 @@ -382,8 +377,8 @@
    8.85  
    8.86  En un proyecto pequeño, usted puede comenzar a trabajar con Mercurial en
    8.87  pocos momentos. Crear nuevos cambios y ramas, transferir cambios (localmente
    8.88 -o por la red); y las operaciones relacionadas con el estado y la
    8.89 -historia son rápidas. Mercurial buscar ser ligero y no incomodar en su
    8.90 +o por la red); y las operaciones relacionadas con el estado y el
    8.91 +historial son rápidas. Mercurial buscar ser ligero y no incomodar en su
    8.92  camino combinando poca sobrecarga cognitiva con operaciones
    8.93  asombrosamente rápidas.
    8.94  
    8.95 @@ -444,8 +439,8 @@
    8.96  información frente a la revisión actual (\texttt{diff}).  Como
    8.97  resultado, la copia de trabajo de Subversion termina siendo del mismo
    8.98  tamaño o más grande que un repositorio de Mercurial y el directorio de
    8.99 -trabajo, a pesar de que el repositorio de Mercurial contiene la
   8.100 -historia completa  del proyecto.
   8.101 +trabajo, a pesar de que el repositorio de Mercurial contiene el
   8.102 +historial completo  del proyecto.
   8.103  
   8.104  Subversion tiene soporte amplio de otras herramientas. Mercurial por
   8.105  ahora está bastante atrás en este aspecto.  Esta diferencia está
   8.106 @@ -453,7 +448,7 @@
   8.107    Usuario Gráfica}, eclipsan sus equivalentes de Subversion. Al igual
   8.108  que Mercurial, Subversion tiene un excelente manual de usuario.
   8.109  
   8.110 -Dado que Subversion no almacena la historia de revisiones en el
   8.111 +Dado que Subversion no almacena el historial de revisiones en el
   8.112  cliente, es muy bueno para administrar proyectos que tienen muchos
   8.113  ficheros binarios grandes y opacos. Si consigna cincuenta revisiones
   8.114  de un fichero de 10MB que no es comprimible, el esapacio en el cliente
   8.115 @@ -469,11 +464,11 @@
   8.116  ventaja significativa en un proyecto donde los ficheros binarios sean
   8.117  usados ampliamente.
   8.118  
   8.119 -Mercurial puede importar la historia de revisiones de un repositorio
   8.120 -de Subversion. También puede exportar historia de revisiones a un
   8.121 +Mercurial puede importar el historial de revisiones de un repositorio
   8.122 +de Subversion. También puede exportar el historial de revisiones a un
   8.123  repositorio de Subversion.  De esta forma es sencillo ``dar un
   8.124  vistazo'' y usar Mercurial y Subversion en paralelo antes de decidirse
   8.125 -a dar el paso. La conversión de la historia es incremental, de modo
   8.126 +a dar el paso. La conversión de el historial es incremental, de modo
   8.127  que puede aplicar una conversión inicial, y después conversiones
   8.128  pequeñas y adicionales posteriormente para traer nuevos cambios.
   8.129  
   8.130 @@ -528,8 +523,7 @@
   8.131  consignar exitósamente parte del cambio y estar bloqueada por la
   8.132  necesidad de una mezcla, forzando a otras personas a ver solamente una
   8.133  porción del trabajo que estaban buscando hacer.  Esto afecta también
   8.134 -%TODO historia/historial
   8.135 -la forma como usted trabaja con la historia del proyecto. Si quiere
   8.136 +la forma como usted trabaja con el historial del proyecto. Si quiere
   8.137  ver todas las modificaciones que alguien hizo como parte de una tarea,
   8.138  necesitará inspeccionar manualmente las descripciones y las marcas de
   8.139  tiempo de cambio de cada fichero involucrado (esto, si usted saber
   8.140 @@ -543,12 +537,12 @@
   8.141  repositorio. Yo no recomendaría un repositorio de CVS para proyecto
   8.142  alguno, ni existente ni nuevo.
   8.143  
   8.144 -Mercurial puede importar la historia de revisiones de CVS.  De todas
   8.145 +Mercurial puede importar el historial de revisiones de CVS.  De todas
   8.146  maneras hay ciertas precauciones que aplican; las cuales también son
   8.147  necesarias para cualquier herramienta importadora de historial de
   8.148  CVS. Debido a la falta de atomicidad de cambios y el no versionamiento
   8.149  de la jerarquía del sistema de ficheros, es imposible reconstruir
   8.150 -completamente la historia de CVS con precisión; hay cierto trabajo de
   8.151 +completamente el historial de CVS con precisión; hay cierto trabajo de
   8.152  conjetura involucrado y los renombramientos tampoco se
   8.153  mostrarán. Debido a que gran parte de la administración avanzada de
   8.154  CVS tiene que hacerse manualmente y por lo tanto es proclive al error,
   8.155 @@ -558,8 +552,7 @@
   8.156  dos de los problemas menos interesantes de los que puedo retomar de mi
   8.157  experiencia personal).
   8.158  
   8.159 -%TODO historia/historial
   8.160 -Mercurial puede importar la historia de revisiones de un repositorio
   8.161 +Mercurial puede importar el historial de revisiones de un repositorio
   8.162  CVS.
   8.163  
   8.164  \subsection{Herramientas comerciales}
   8.165 @@ -596,7 +589,7 @@
   8.166  Mercurial viene con una extensión llamada \hgext{convert}, que puede
   8.167  importar historiales de revisiones de forma incremental desde varias
   8.168  herramientas de control de revisiones. Por ``incremental'', quiero
   8.169 -decir que puede migrar toda la historia de un proyecto en una primera
   8.170 +decir que puede migrar toda el historial de un proyecto en una primera
   8.171  instancia y después volver a ejecutar la migración posteriormente para
   8.172  obtener los nuevos cambios que han sucedido después de la migración
   8.173  inicial.

     9.1 --- a/es/mq-collab.tex	Sun Jan 18 21:01:13 2009 -0500
     9.2 +++ b/es/mq-collab.tex	Sun Jan 18 21:37:11 2009 -0500
     9.3 @@ -351,13 +351,13 @@
     9.4  tiene problemas manejando nombres de parches que contienen separadores
     9.5  de ruta.
     9.6  
     9.7 -\subsection{Ver la historia de un parche}
     9.8 +\subsection{Ver el historial de un parche}
     9.9  \label{mq-collab:tips:interdiff}
    9.10  
    9.11  Si usted está desarrollando un conjunto de parches en un período de
    9.12  tiempo grande, es una buena idea mantenerlos en un repositorio, como
    9.13  se discutió en la sección~\ref{sec:mq:repo}.  Si lo hace, notará
    9.14 -rápidamente que usar el comando \hgcmd{diff} para mirar la historia
    9.15 +rápidamente que usar el comando \hgcmd{diff} para mirar el historial
    9.16  del repositorio no es viable. Esto es debido en parte a que usted está
    9.17  mirando la segunda derivada del código real (el diff de un diff), pero
    9.18  también porque MQ añade ruido al proceso al modificar las marcas de

    10.1 --- a/es/mq-ref.tex	Sun Jan 18 21:01:13 2009 -0500
    10.2 +++ b/es/mq-ref.tex	Sun Jan 18 21:37:11 2009 -0500
    10.3 @@ -257,7 +257,7 @@
    10.4    el nuevo conjunto de cambios que representa el parche.
    10.5  \item Las modificaciones a los ficheros a los que se les da
    10.6    seguimiento en el directorio de trabajo se añade al parche.
    10.7 -\item Los cambios a los archivos a los que se les da seguimiento con
    10.8 +\item Los cambios a los ficheros a los que se les da seguimiento con
    10.9    \hgcmd{add}, \hgcmd{copy}, \hgcmd{remove}, o \hgcmd{rename}.  Se
   10.10    añaden al parche los ficheros añadidos, copiados y renombrados,
   10.11    mientras que los ficheros eliminados y las fuentes renombradas se

    11.1 --- a/es/mq.tex	Sun Jan 18 21:01:13 2009 -0500
    11.2 +++ b/es/mq.tex	Sun Jan 18 21:37:11 2009 -0500
    11.3 @@ -147,7 +147,7 @@
    11.4  
    11.5  En contraste, con la cohesión de MQ con el control de revisiones
    11.6  distribuidos y los parches, resulta más sencillo aislar su trabajo.
    11.7 -Sus parches viven encima de la historia de revisiones normales, y
    11.8 +Sus parches viven encima de el historial de revisiones normales, y
    11.9  puede hacer que ellos desaparezcan o reaparezcan cuando lo desee.  Si
   11.10  no le gusta un parche, puede desecharlo.  Si un parche no satisface
   11.11  todo lo que usted desea, puede arreglarlo---tantas veces como lo

    12.1 --- a/es/template.tex	Sun Jan 18 21:01:13 2009 -0500
    12.2 +++ b/es/template.tex	Sun Jan 18 21:37:11 2009 -0500
    12.3 @@ -485,7 +485,7 @@
    12.4  Podríamos haber incluído el texto del fichero plantilla directamente
    12.5  en el fichero de estilo encerrando entre comillas y reemplazando las
    12.6  nuevas líneas con secuencias ``\verb!\n!'', pero haría muy difícil de
    12.7 -leer el archivo de estilos.  La facilidad para leer es importante
    12.8 +leer el fichero de estilos.  La facilidad para leer es importante
    12.9  cuando está decidiendo si un texto pertenece a un fichero de estilo o
   12.10  a un fichero de plantilla incluído en el estilo.  Si el fichero de
   12.11  estilo luce muy grande o complicado, si inserta una pieza de texto

    13.1 --- a/es/tour-basic.tex	Sun Jan 18 21:01:13 2009 -0500
    13.2 +++ b/es/tour-basic.tex	Sun Jan 18 21:37:11 2009 -0500
    13.3 @@ -144,7 +144,7 @@
    13.4  repositorio y en el repositorio que clonamos.
    13.5  
    13.6  Cada repositorio Mercurial está completo, es autocontenido e
    13.7 -independiente. Contiene su propia copia de los ficheros y la historia
    13.8 +independiente. Contiene su propia copia de los ficheros y el historial
    13.9  de un proyecto. Un repositorio clonado recuerda la ubicación de la que
   13.10  fue clonado, pero no se comunica con ese repositorio, ni con ningún
   13.11  otro, a menos que usted le indique que lo haga.
   13.12 @@ -169,7 +169,6 @@
   13.13  el repositorio ``real'', y todos los ficheros y directorios que
   13.14  coexisten con él están en el \emph{directorio de trabajo}. Una forma
   13.15  sencilla de recordar esta distinción es que el \emph{repositorio}
   13.16 -% TODO unificar con Igor, si historia o historial
   13.17  contiene el \emph{historial} de su proyecto, mientras que el
   13.18  \emph{directorio de trabajo} contiene una \emph{instantánea} de su
   13.19  proyecto en un punto particular del historial.

    14.1 --- a/es/tour-merge.tex	Sun Jan 18 21:01:13 2009 -0500
    14.2 +++ b/es/tour-merge.tex	Sun Jan 18 21:37:11 2009 -0500
    14.3 @@ -164,7 +164,7 @@
    14.4  \command{kdiff3} ejecutándose, en la
    14.5  figura~\ref{fig:tour-merge:kdiff3}.  El tipo de fusión que la
    14.6  herramienta hace se conoce como \emph{fusión de tres vías}, porque hay
    14.7 -tres versiones diferentes del archivo en que estamos interesados.
    14.8 +tres versiones diferentes del fichero en que estamos interesados.
    14.9  Debido a esto la herramienta divide la parte superior de la ventana en
   14.10  tres paneles.
   14.11  \begin{itemize}
   14.12 @@ -204,7 +204,7 @@
   14.13  diferencian en las plataformas para las que están disponibles, y en
   14.14  sus fortalezas y debilidades particulares. La mayoría están afinadas
   14.15  para fusionar texto plano, mientras que otras están pensadas para
   14.16 -formatos de archivos especializados (generalmente XML).
   14.17 +formatos de ficheros especializados (generalmente XML).
   14.18  
   14.19  % TODO traduje "worked" como "real"
   14.20  \subsection{Un ejemplo real}

    15.1 --- a/es/undo.tex	Sun Jan 18 21:01:13 2009 -0500
    15.2 +++ b/es/undo.tex	Sun Jan 18 21:37:11 2009 -0500
    15.3 @@ -8,7 +8,7 @@
    15.4  tiene unas características poderosas que le ayudarán a isolar las
    15.5  fuentes de los problemas, y a dar cuenta de ellas apropiadamente.
    15.6  
    15.7 -\section{Borrar la historia local}
    15.8 +\section{Borrar el historial local}
    15.9  
   15.10  \subsection{La consignación accidental}
   15.11  
   15.12 @@ -51,7 +51,7 @@
   15.13  el conjunto de cambios.  Uso la orden \hgcmd{rollback}, y Mercurial
   15.14  hace desaparecer el último conjunto de cambios.
   15.15  \interaction{rollback.rollback}
   15.16 -El conjunto de cambios ya no está en la historia del repositorio, y el
   15.17 +El conjunto de cambios ya no está en el historial del repositorio, y el
   15.18  directorio de trabajo cree que el fichero \filename{a} ha sido
   15.19  modificado.  La consignación y el roll back dejaron el directorio de
   15.20  trabajo exactamente como estaba antes de la consignación; el conjunto
   15.21 @@ -88,7 +88,7 @@
   15.22  El valor de \hgcmd{rollback} se anula cuando ha publicado sus cambios
   15.23  a otro repositorio.  Un cambio desaparece totalmente al hacer roll back,
   15.24  pero \emph{solamente} en el repositorio en el cual aplica
   15.25 -\hgcmd{rollback}.  Debido a que un roll back elimina la historia,
   15.26 +\hgcmd{rollback}.  Debido a que un roll back elimina el historial,
   15.27  no hay forma de que la desaparición de un cambio se propague entre
   15.28  repositorios.
   15.29  
   15.30 @@ -220,7 +220,7 @@
   15.31  parte de un conjunto de cambios a mano.
   15.32  
   15.33  Antes de leer esta sección, hay algo para tener en cuenta: la orden
   15.34 -\hgcmd{backout} deshace cambios \emph{adicionando} a la historia, sin
   15.35 +\hgcmd{backout} deshace cambios \emph{adicionando} a el historial, sin
   15.36  modificar o borrar.  Es la herramienta correcta si está arreglando
   15.37  fallos, pero no si está tratando de deshacer algún cambio que tiene
   15.38  consecuencias catastróficas.  Para tratar con esos, vea la sección~\ref{sec:undo:aaaiiieee}.
   15.39 @@ -228,7 +228,7 @@
   15.40  \subsection{Retroceder un conjunto de cambios}
   15.41  
   15.42  La orden \hgcmd{backout} le permite ``deshacer'' los efectos de todo
   15.43 -un conjunto de cambios de forma automatizada.  Dado que la historia de
   15.44 +un conjunto de cambios de forma automatizada.  Dado que el historial de
   15.45  Mercurial es inmutable, esta orden \emph{no} se deshace del conjunto
   15.46  de cambios que usted desea deshacer.  En cambio, crea un nuevo
   15.47  conjunto de cambios que \emph{reversa} el conjunto de cambios que
   15.48 @@ -257,8 +257,8 @@
   15.49  Vea que el nuevo conjunto de cambios que \hgcmd{backout} ha creado es
   15.50  un hijo del conjunto de cambios que retrocedimos. Es más sencillo de
   15.51  ver en la figura~\ref{fig:undo:backout}, que presenta una vista
   15.52 -gráfica de la historia de cambios.  Como puede ver, la historia es
   15.53 -bonita y lineal.
   15.54 +gráfica de el historial de cambios.  Como puede ver, el historial es
   15.55 +bonito y lineal.
   15.56  
   15.57  \begin{figure}[htb]
   15.58    \centering
   15.59 @@ -281,7 +281,7 @@
   15.60  presentes, pero no el segundo.
   15.61  \interaction{backout.non-tip.cat}
   15.62  
   15.63 -Como lo muestra la historia gráfica en la
   15.64 +Como lo muestra el historial gráfico en la
   15.65  figura~\ref{fig:undo:backout-non-tip}, Mercurial realmente consigna
   15.66  \emph{dos} cambios en estas situaciones (los nodos encerrados en una
   15.67  caja son aquellos que Mercurial consigna automaticamente).  Antes de
   15.68 @@ -301,7 +301,7 @@
   15.69  \end{figure}
   15.70  
   15.71  El resultado es que usted termina ``donde estaba'', solamente con un
   15.72 -poco de historia adicional que deshace el efecto de un conjunto de
   15.73 +poco de historial adicional que deshace el efecto de un conjunto de
   15.74  cambios que usted quería evitar.
   15.75  
   15.76  \subsubsection{Use siempre la opción \hgopt{backout}{--merge}}
   15.77 @@ -333,8 +333,8 @@
   15.78  orden \hgcmd{backout} fue muy explícita diciéndolo.
   15.79  \interaction{backout.manual.log}
   15.80  
   15.81 -De nuevo, es más sencillo lo que pasó viendo una gráfica de la
   15.82 -historia de revisiones, en la figura~\ref{fig:undo:backout-manual}.
   15.83 +De nuevo, es más sencillo lo que pasó viendo una gráfica del
   15.84 +historial de revisiones, en la figura~\ref{fig:undo:backout-manual}.
   15.85  Esto nos aclara que cuando usamos \hgcmd{backout} para retroceder un
   15.86  cambio a algo que no sea la punta, Mercurial añade una nueva cabeza al
   15.87  repositorio (el cambio que consignó está encerrado en una caja).
   15.88 @@ -355,14 +355,14 @@
   15.89  Reflexionemos acerca de lo que esperamos ver como contenidos de
   15.90  \filename{myfile}.  El primer cambio debería estar presente, porque
   15.91  nunca le hicimos retroceso.  El segundo cambio debió desaparecer,
   15.92 -puesto que es el que retrocedimos.  Dado que la gráfica de la historia
   15.93 +puesto que es el que retrocedimos.  Dado que la gráfica de el historial
   15.94  muestra que el tercer camlio es una cabeza separada, \emph{no}
   15.95  esperamos ver el tercer cambio presente en \filename{myfile}.
   15.96  \interaction{backout.manual.cat}
   15.97  Para que el tercer cambio esté en el fichero, hacemos una fusión usual
   15.98  de las dos cabezas.
   15.99  \interaction{backout.manual.merge}
  15.100 -Después de eso, la historia gráfica de nuestro repositorio luce como
  15.101 +Después de eso, el historial gráfica de nuestro repositorio luce como
  15.102  la figura~\ref{fig:undo:backout-manual-merge}.
  15.103  
  15.104  \begin{figure}[htb]
  15.105 @@ -411,7 +411,7 @@
  15.106  retrocediendo y la punta actual.
  15.107  
  15.108  Si está retrocediendo un conjunto de cambios que está a unas ~100
  15.109 -atrás en su historia del proyecto, las posibilidades de que una orden
  15.110 +atrás en su historial del proyecto, las posibilidades de que una orden
  15.111  \command{patch} sea capaz de ser aplicada a un diff reverso,
  15.112  claramente no son altas, porque los cambios que intervienen podrían
  15.113  ``no coincidir con el contexto'' que \command{patch} usa  para
  15.114 @@ -442,13 +442,13 @@
  15.115  colocarse una bolsa de papel desechable en su cabeza), permítame
  15.116  discutir primero unas aproximaciones que probablemente no funcionen.
  15.117  
  15.118 -Dado que Mercurial trata de forma acumulativa la historia---cada
  15.119 -cambio se coloca encima de todos los cambios que leo
  15.120 -preceden---usualmente usted no puede hacer que unos cambios desastros
  15.121 +Dado que Mercurial trata de forma acumulativa al historial---cada
  15.122 +cambio se coloca encima de todos los cambios que le
  15.123 +preceden---usualmente usted no puede hacer que unos cambios desastrosos
  15.124  desaparezcan. La única excepción es cuando usted ha acabado de
  15.125  consignar un cambio y este no ha sido publicado o jalado en otro
  15.126  repositorio. Ahí es cuando puede usar la orden \hgcmd{rollback} con
  15.127 -seguridad, Como detallé en la sección~\ref{sec:undo:rollback}.
  15.128 +seguridad, como detallé en la sección~\ref{sec:undo:rollback}.
  15.129  
  15.130  Después de que usted haya publicado un cambio en otro repositorio, usted
  15.131  \emph{podría} usar la orden \hgcmd{rollback} para hacer que en su copia
  15.132 @@ -466,7 +466,7 @@
  15.133  
  15.134  Si ha consignado uno o más cambios \emph{después} del cambio que desea
  15.135  desaparecer, sus opciones son aún más reducidas. Mercurial no provee
  15.136 -una forma de ``cabar un hueco'' en la historia, dejando los conjuntos
  15.137 +una forma de ``cabar un hueco'' en el historial, dejando los conjuntos
  15.138  de cambios intactos.
  15.139  
  15.140  %Dejamos de traducir lo que viene a continuación, porque será
  15.141 @@ -561,20 +561,20 @@
  15.142  búsqueda a ellos, estaría tomabdi más de 40 horas para encontrar al
  15.143  conjunto de cambios culpable.
  15.144  
  15.145 -La orden \hgcmd{bisect} usa su conocimiento de la ``forma'' de la
  15.146 -historia de revisiones de su proyecto para hacer una búsqueda
  15.147 +La orden \hgcmd{bisect} usa su conocimiento de la ``forma'' del
  15.148 +historial de revisiones de su proyecto para hacer una búsqueda
  15.149  proporcional al \emph{logaritmo} del número de conjunto de cambios a
  15.150 -revisar( el tipo de búsqueda que realiza se llama búsqueda
  15.151 +revisar (el tipo de búsqueda que realiza se llama búsqueda
  15.152  binaria). Con esta aproximación, el buscar entre 10.000 conjuntos de
  15.153 -cambios tomará menos de 3 horas, incluso a diez minutos por prueba(La
  15.154 +cambios tomará menos de 3 horas, incluso a diez minutos por prueba (La
  15.155  búsqueda requerirá cerca de 14 pruebas). Al limitar la búsqueda a la
  15.156  última centena de conjuntos de cambios, tomará a lo sumo una
  15.157 -hora(Apenas unas 7 pruebas).
  15.158 +hora (Apenas unas 7 pruebas).
  15.159  
  15.160  La orden \hgcmd{bisect} tiene en cuenta la naturaleza ``ramificada''
  15.161 -de la historia de revisiones del proyecto con Mercurial, así que no
  15.162 +de el historial de revisiones del proyecto con Mercurial, así que no
  15.163  hay problemas al tratar con ramas, fusiones o cabezas múltiples en un
  15.164 -repositorio.  Puede evitar ramas enteras de historia con un solo
  15.165 +repositorio.  Puede evitar ramas enteras de historial con un solo
  15.166  sondeo.
  15.167  
  15.168  \subsection{Uso de la orden \hgcmd{bisect}}
  15.169 @@ -790,7 +790,7 @@
  15.170  otro fallo puede enmascararlo(como se discutió anteriormente).
  15.171  
  15.172  Incluso si termina ``muy atrás'' por miles de conjuntos de cambios o
  15.173 -meses de historia, solamente estaŕa adicionando unas pruebas contadas
  15.174 +meses de historial, solamente estaŕa adicionando unas pruebas contadas
  15.175  para \hgcmd{bisect}, gracias al comportamiento logarítmico.
  15.176  
  15.177  %%% Local Variables: