# HG changeset patch # User Javier Rojas # Date 1232332776 18000 # Node ID 3f32047a3f25a256ccb20458a4dafa150d3cc9c0 # Parent 9da096de3c52266be6cdde4994d70e20218cc8b1 changed all "de el" to "del" diff -r 9da096de3c52 -r 3f32047a3f25 es/branch.tex --- 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} diff -r 9da096de3c52 -r 3f32047a3f25 es/collab.tex --- 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} diff -r 9da096de3c52 -r 3f32047a3f25 es/concepts.tex --- 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 diff -r 9da096de3c52 -r 3f32047a3f25 es/intro.tex --- 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. diff -r 9da096de3c52 -r 3f32047a3f25 es/mq.tex --- 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 diff -r 9da096de3c52 -r 3f32047a3f25 es/tour-merge.tex --- 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. diff -r 9da096de3c52 -r 3f32047a3f25 es/undo.tex --- 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.