Mercurial > hgbook

--- a/es/branch.tex	Sun Jan 18 21:37:11 2009 -0500
+++ b/es/branch.tex	Sun Jan 18 21:39:36 2009 -0500
@@ -153,7 +153,7 @@
 \hgcmdargs{clone}{-r foo} para clonar un repositorio hasta el tag
 \texttt{foo}, el nuevo clon \emph{no contendrá el historial que creo
 el tag} que usó para clonar el repositorio. El resultado es que tendrá
-exactamente el subconjunto correcto de el historial del proyecto en el
+exactamente el subconjunto correcto del historial del proyecto en el
 nuevo repositorio, pero, \emph{no} el tag que podría haber esperado.

 \subsection{Cuando las etiquetas permanentes son demasiado}
--- a/es/collab.tex	Sun Jan 18 21:37:11 2009 -0500
+++ b/es/collab.tex	Sun Jan 18 21:39:36 2009 -0500
@@ -785,7 +785,7 @@
 completa al repositorio que desea servir.

 En este punto, cuando trate de recargar la página, deberá visualizar
-una linda vista HTML de el historial de su repositorio. Uff!
+una linda vista HTML del historial de su repositorio. Uff!

 \subsubsection{Configuración de lighttpd}
--- a/es/concepts.tex	Sun Jan 18 21:37:11 2009 -0500
+++ b/es/concepts.tex	Sun Jan 18 21:39:36 2009 -0500
@@ -504,7 +504,7 @@

 Si la conexión es hecha a través de HTTP, Mercurial recomprime el
 flujo completo de datos usando un algoritmo de compresión que brinda
-una mejor tasa de compresión (el algoritmo Burrows-Wheeler de el
+una mejor tasa de compresión (el algoritmo Burrows-Wheeler del
 ampliamente usado paquete de compresión \texttt{bzip2}). Esta
 combinación de algoritmo y compresión del flujo completo de datos
 (en vez de una revisión a la vez) reduce sustancialmente la cantidad
--- a/es/intro.tex	Sun Jan 18 21:37:11 2009 -0500
+++ b/es/intro.tex	Sun Jan 18 21:39:36 2009 -0500
@@ -26,7 +26,7 @@
 Hay muchas razones por las cuales usted o su equipo desearía usar una
 herramienta automática de control de revisiones para un proyecto.
 \begin{itemize}
-\item Llevar registro de el historial y la evolución de su proyecto, para
+\item Llevar registro del historial y la evolución de su proyecto, para
   evitar hacer la tarea manualmente. Por cada cambio, tendrá una
   bitácora de \emph{quién} lo hizo; \emph{por qué} se hizo;
   \emph{cuándo} se hizo; y de \emph{qué} se trataba el cambio.
@@ -145,7 +145,7 @@
 A comienzos de los noventa~(1990s), Sun MicroSystems desarrollo un
 temprano sistema distribuido de control de revisiones llamado
 TeamWare.
-Un espacio de trabajo TeamWare contiene una copia completa de el
+Un espacio de trabajo TeamWare contiene una copia completa del
 historial del proyecto. TeamWare no tiene la noción de repositorio
 central. (CVS se basaba en RCS para el almacenamiento de su historial;
 TeamWare usaba SCCS.)
@@ -468,7 +468,7 @@
 de Subversion. También puede exportar el historial de revisiones a un
 repositorio de Subversion.  De esta forma es sencillo ``dar un
 vistazo'' y usar Mercurial y Subversion en paralelo antes de decidirse
-a dar el paso. La conversión de el historial es incremental, de modo
+a dar el paso. La conversión del historial es incremental, de modo
 que puede aplicar una conversión inicial, y después conversiones
 pequeñas y adicionales posteriormente para traer nuevos cambios.
--- a/es/mq.tex	Sun Jan 18 21:37:11 2009 -0500
+++ b/es/mq.tex	Sun Jan 18 21:39:36 2009 -0500
@@ -147,7 +147,7 @@

 En contraste, con la cohesión de MQ con el control de revisiones
 distribuidos y los parches, resulta más sencillo aislar su trabajo.
-Sus parches viven encima de el historial de revisiones normales, y
+Sus parches viven encima del historial de revisiones normales, y
 puede hacer que ellos desaparezcan o reaparezcan cuando lo desee.  Si
 no le gusta un parche, puede desecharlo.  Si un parche no satisface
 todo lo que usted desea, puede arreglarlo---tantas veces como lo
@@ -865,7 +865,7 @@
 parches.

 Esto presenta la interesante posibilidad de administrar los contenidos
-de el directorio de parches como un repositorio de Mercurial por su
+del directorio de parches como un repositorio de Mercurial por su
 cuenta.  Puede ser una forma útil de trabajar.  Por ejemplo, puede
 trabajar en un parche por un rato, hacerle \hgxcmd{mq}{qrefresh} y
 después hacer \hgcmd{commit} al estado actual del parche.  Esto le
--- a/es/tour-merge.tex	Sun Jan 18 21:37:11 2009 -0500
+++ b/es/tour-merge.tex	Sun Jan 18 21:39:36 2009 -0500
@@ -136,7 +136,7 @@

 La figura~\ref{fig:tour-merge:conflict} ilustra un ejemplo con dos
 cambios generando conflictos en un documento. Empezamos con una sola
-versión de el fichero; luego hicimos algunos cambios; mientras tanto,
+versión del fichero; luego hicimos algunos cambios; mientras tanto,
 alguien más  hizo cambios diferentes en el mismo texto. Lo que debemos
 hacer para resolver el conflicto causado por ambos cambios es decidir
 cómo debe quedar finalmente el fichero.
--- a/es/undo.tex	Sun Jan 18 21:37:11 2009 -0500
+++ b/es/undo.tex	Sun Jan 18 21:39:36 2009 -0500
@@ -257,7 +257,7 @@
 Vea que el nuevo conjunto de cambios que \hgcmd{backout} ha creado es
 un hijo del conjunto de cambios que retrocedimos. Es más sencillo de
 ver en la figura~\ref{fig:undo:backout}, que presenta una vista
-gráfica de el historial de cambios.  Como puede ver, el historial es
+gráfica del historial de cambios.  Como puede ver, el historial es
 bonito y lineal.

 \begin{figure}[htb]
@@ -355,7 +355,7 @@
 Reflexionemos acerca de lo que esperamos ver como contenidos de
 \filename{myfile}.  El primer cambio debería estar presente, porque
 nunca le hicimos retroceso.  El segundo cambio debió desaparecer,
-puesto que es el que retrocedimos.  Dado que la gráfica de el historial
+puesto que es el que retrocedimos.  Dado que la gráfica del historial
 muestra que el tercer camlio es una cabeza separada, \emph{no}
 esperamos ver el tercer cambio presente en \filename{myfile}.
 \interaction{backout.manual.cat}
@@ -572,7 +572,7 @@
 hora (Apenas unas 7 pruebas).

 La orden \hgcmd{bisect} tiene en cuenta la naturaleza ``ramificada''
-de el historial de revisiones del proyecto con Mercurial, así que no
+del historial de revisiones del proyecto con Mercurial, así que no
 hay problemas al tratar con ramas, fusiones o cabezas múltiples en un
 repositorio.  Puede evitar ramas enteras de historial con un solo
 sondeo.