1.1 --- a/es/branch.tex	Sun Jan 18 21:37:11 2009 -0500
     1.2 +++ b/es/branch.tex	Sun Jan 18 21:39:36 2009 -0500
     1.3 @@ -153,7 +153,7 @@
     1.4  \hgcmdargs{clone}{-r foo} para clonar un repositorio hasta el tag
     1.5  \texttt{foo}, el nuevo clon \emph{no contendrá el historial que creo
     1.6  el tag} que usó para clonar el repositorio. El resultado es que tendrá
     1.7 -exactamente el subconjunto correcto de el historial del proyecto en el
     1.8 +exactamente el subconjunto correcto del historial del proyecto en el
     1.9  nuevo repositorio, pero, \emph{no} el tag que podría haber esperado.
    1.10  
    1.11  \subsection{Cuando las etiquetas permanentes son demasiado}

     2.1 --- a/es/collab.tex	Sun Jan 18 21:37:11 2009 -0500
     2.2 +++ b/es/collab.tex	Sun Jan 18 21:39:36 2009 -0500
     2.3 @@ -785,7 +785,7 @@
     2.4  completa al repositorio que desea servir.
     2.5  
     2.6  En este punto, cuando trate de recargar la página, deberá visualizar
     2.7 -una linda vista HTML de el historial de su repositorio. Uff!
     2.8 +una linda vista HTML del historial de su repositorio. Uff!
     2.9  
    2.10  \subsubsection{Configuración de lighttpd}
    2.11  

     3.1 --- a/es/concepts.tex	Sun Jan 18 21:37:11 2009 -0500
     3.2 +++ b/es/concepts.tex	Sun Jan 18 21:39:36 2009 -0500
     3.3 @@ -504,7 +504,7 @@
     3.4  
     3.5  Si la conexión es hecha a través de HTTP, Mercurial recomprime el
     3.6  flujo completo de datos usando un algoritmo de compresión que brinda
     3.7 -una mejor tasa de compresión (el algoritmo Burrows-Wheeler de el
     3.8 +una mejor tasa de compresión (el algoritmo Burrows-Wheeler del
     3.9  ampliamente usado paquete de compresión \texttt{bzip2}). Esta
    3.10  combinación de algoritmo y compresión del flujo completo de datos
    3.11  (en vez de una revisión a la vez) reduce sustancialmente la cantidad

     4.1 --- a/es/intro.tex	Sun Jan 18 21:37:11 2009 -0500
     4.2 +++ b/es/intro.tex	Sun Jan 18 21:39:36 2009 -0500
     4.3 @@ -26,7 +26,7 @@
     4.4  Hay muchas razones por las cuales usted o su equipo desearía usar una
     4.5  herramienta automática de control de revisiones para un proyecto.
     4.6  \begin{itemize}
     4.7 -\item Llevar registro de el historial y la evolución de su proyecto, para
     4.8 +\item Llevar registro del historial y la evolución de su proyecto, para
     4.9    evitar hacer la tarea manualmente. Por cada cambio, tendrá una
    4.10    bitácora de \emph{quién} lo hizo; \emph{por qué} se hizo;
    4.11    \emph{cuándo} se hizo; y de \emph{qué} se trataba el cambio.
    4.12 @@ -145,7 +145,7 @@
    4.13  A comienzos de los noventa~(1990s), Sun MicroSystems desarrollo un
    4.14  temprano sistema distribuido de control de revisiones llamado
    4.15  TeamWare.
    4.16 -Un espacio de trabajo TeamWare contiene una copia completa de el
    4.17 +Un espacio de trabajo TeamWare contiene una copia completa del
    4.18  historial del proyecto. TeamWare no tiene la noción de repositorio
    4.19  central. (CVS se basaba en RCS para el almacenamiento de su historial;
    4.20  TeamWare usaba SCCS.)
    4.21 @@ -468,7 +468,7 @@
    4.22  de Subversion. También puede exportar el historial de revisiones a un
    4.23  repositorio de Subversion.  De esta forma es sencillo ``dar un
    4.24  vistazo'' y usar Mercurial y Subversion en paralelo antes de decidirse
    4.25 -a dar el paso. La conversión de el historial es incremental, de modo
    4.26 +a dar el paso. La conversión del historial es incremental, de modo
    4.27  que puede aplicar una conversión inicial, y después conversiones
    4.28  pequeñas y adicionales posteriormente para traer nuevos cambios.
    4.29  

     5.1 --- a/es/mq.tex	Sun Jan 18 21:37:11 2009 -0500
     5.2 +++ b/es/mq.tex	Sun Jan 18 21:39:36 2009 -0500
     5.3 @@ -147,7 +147,7 @@
     5.4  
     5.5  En contraste, con la cohesión de MQ con el control de revisiones
     5.6  distribuidos y los parches, resulta más sencillo aislar su trabajo.
     5.7 -Sus parches viven encima de el historial de revisiones normales, y
     5.8 +Sus parches viven encima del historial de revisiones normales, y
     5.9  puede hacer que ellos desaparezcan o reaparezcan cuando lo desee.  Si
    5.10  no le gusta un parche, puede desecharlo.  Si un parche no satisface
    5.11  todo lo que usted desea, puede arreglarlo---tantas veces como lo
    5.12 @@ -865,7 +865,7 @@
    5.13  parches.
    5.14  
    5.15  Esto presenta la interesante posibilidad de administrar los contenidos
    5.16 -de el directorio de parches como un repositorio de Mercurial por su
    5.17 +del directorio de parches como un repositorio de Mercurial por su
    5.18  cuenta.  Puede ser una forma útil de trabajar.  Por ejemplo, puede
    5.19  trabajar en un parche por un rato, hacerle \hgxcmd{mq}{qrefresh} y
    5.20  después hacer \hgcmd{commit} al estado actual del parche.  Esto le

     6.1 --- a/es/tour-merge.tex	Sun Jan 18 21:37:11 2009 -0500
     6.2 +++ b/es/tour-merge.tex	Sun Jan 18 21:39:36 2009 -0500
     6.3 @@ -136,7 +136,7 @@
     6.4  
     6.5  La figura~\ref{fig:tour-merge:conflict} ilustra un ejemplo con dos
     6.6  cambios generando conflictos en un documento. Empezamos con una sola
     6.7 -versión de el fichero; luego hicimos algunos cambios; mientras tanto,
     6.8 +versión del fichero; luego hicimos algunos cambios; mientras tanto,
     6.9  alguien más  hizo cambios diferentes en el mismo texto. Lo que debemos
    6.10  hacer para resolver el conflicto causado por ambos cambios es decidir
    6.11  cómo debe quedar finalmente el fichero.

     7.1 --- a/es/undo.tex	Sun Jan 18 21:37:11 2009 -0500
     7.2 +++ b/es/undo.tex	Sun Jan 18 21:39:36 2009 -0500
     7.3 @@ -257,7 +257,7 @@
     7.4  Vea que el nuevo conjunto de cambios que \hgcmd{backout} ha creado es
     7.5  un hijo del conjunto de cambios que retrocedimos. Es más sencillo de
     7.6  ver en la figura~\ref{fig:undo:backout}, que presenta una vista
     7.7 -gráfica de el historial de cambios.  Como puede ver, el historial es
     7.8 +gráfica del historial de cambios.  Como puede ver, el historial es
     7.9  bonito y lineal.
    7.10  
    7.11  \begin{figure}[htb]
    7.12 @@ -355,7 +355,7 @@
    7.13  Reflexionemos acerca de lo que esperamos ver como contenidos de
    7.14  \filename{myfile}.  El primer cambio debería estar presente, porque
    7.15  nunca le hicimos retroceso.  El segundo cambio debió desaparecer,
    7.16 -puesto que es el que retrocedimos.  Dado que la gráfica de el historial
    7.17 +puesto que es el que retrocedimos.  Dado que la gráfica del historial
    7.18  muestra que el tercer camlio es una cabeza separada, \emph{no}
    7.19  esperamos ver el tercer cambio presente en \filename{myfile}.
    7.20  \interaction{backout.manual.cat}
    7.21 @@ -572,7 +572,7 @@
    7.22  hora (Apenas unas 7 pruebas).
    7.23  
    7.24  La orden \hgcmd{bisect} tiene en cuenta la naturaleza ``ramificada''
    7.25 -de el historial de revisiones del proyecto con Mercurial, así que no
    7.26 +del historial de revisiones del proyecto con Mercurial, así que no
    7.27  hay problemas al tratar con ramas, fusiones o cabezas múltiples en un
    7.28  repositorio.  Puede evitar ramas enteras de historial con un solo
    7.29  sondeo.