Mercurial > hgbook
changeset 615:9da096de3c52
changed "historia" to "historial".
changed "archivo" to "fichero"
corrected some typos
| author | Javier Rojas <jerojasro@devnull.li> |
|---|---|
| date | Sun, 18 Jan 2009 21:37:11 -0500 |
| parents | aa01d35ac59f |
| children | 3f32047a3f25 |
| files | es/branch.tex es/cmdref.tex es/collab.tex es/concepts.tex es/daily.tex es/filenames.tex es/hgext.tex es/intro.tex es/mq-collab.tex es/mq-ref.tex es/mq.tex es/template.tex es/tour-basic.tex es/tour-merge.tex es/undo.tex |
| diffstat | 15 files changed, 106 insertions(+), 114 deletions(-) [+] |
line wrap: on
line diff
--- a/es/branch.tex Sun Jan 18 21:01:13 2009 -0500 +++ b/es/branch.tex Sun Jan 18 21:37:11 2009 -0500 @@ -104,35 +104,35 @@ mover el tag hacia la revisión correcta tan pronto como localice el error. -Mercurial almacena las etiquetas en un archivo controlado por revisiones en -su repositorio. Si ha creado etiquetas, las encontrará en un archivo +Mercurial almacena las etiquetas en un fichero controlado por revisiones en +su repositorio. Si ha creado etiquetas, las encontrará en un fichero llamado \sfilename{.hgtags}. Cuando invoca la orden \hgcmd{tag}, -Mercurial modifica este archivo, y automáticamente hace consignación del +Mercurial modifica este fichero, y automáticamente hace consignación del cambio al mismo. Esto significa que cada vez que ejecuta \hgcmd{tag}, verá el conjunto de cambios correspondiente en la salida de \hgcmd{log}. \interaction{tag.tip} \subsection{Manejo de conflictos entre etiquetas durante una fusión} -Es usual no tener que preocuparse por el archivo \sfilename{.hgtags}, +Es usual no tener que preocuparse por el fichero \sfilename{.hgtags}, pero aveces hace su aparición durante una fusión. El formato del -archivo es sencillo: Consiste de una serie de líneas. Cada línea +fichero es sencillo: Consiste de una serie de líneas. Cada línea comienza con un hash de Conjunto de Cambios, seguido por un espacio, seguido por el nombre de un tag. -Si está resolviendo un conflicto en el archivo \sfilename{.hgtags} +Si está resolviendo un conflicto en el fichero \sfilename{.hgtags} durante una fusión, hay un detalle para tener en cuenta al modificar -el archivo \sfilename{.hgtags}: +el fichero \sfilename{.hgtags}: cuando Mercurial parsea las etiquetas en el repositorio \emph{nunca} -lee la copia de trabajo del archivo \sfilename{.hgtags}. En cambio, -lee la versión \emph{consignada más reciente} del archivo. +lee la copia de trabajo del fichero \sfilename{.hgtags}. En cambio, +lee la versión \emph{consignada más reciente} del fichero. Una consecuencia desafortunada de este diseño es que usted no puede -verificar que su archivo \sfilename{.hgtags} fusionado es correcto hasta +verificar que su fichero \sfilename{.hgtags} fusionado es correcto hasta \emph{después} de haber consignado(hecho commit). Así que si se encuentra resolviendo un conflicto en \sfilename{.hgtags} durante una fusión, asegúrese de ejecutar la orden \hgcmd{tags} después de -consignar. Si encuentra un error en el archivo \sfilename{.hgtags}, +consignar. Si encuentra un error en el fichero \sfilename{.hgtags}, reportará el lugar del error, que podrá arreglar y después consignar. Posteriormente ejecute de nuevo la orden \hgcmd{tags} para asegurar que su arreglo fue correctamente aplicado. @@ -142,24 +142,24 @@ Puede haber notado que la orden \hgcmd{clone} tiene la opción \hgopt{clone}{-r} que le permite clonar una copia exacta del repositorio hasta un conjunto de cambios específico. El nuevo clon no -tendrá historia posterior a la revisión que usted haya +tendrá historial posterior a la revisión que usted haya especificado. Esta forma de interactuar puede sorprender a los desprevenidos. -Recuerde que un tag se almacena como una revisión al archivo +Recuerde que un tag se almacena como una revisión al fichero \sfilename{.hgtags}, consecuente con esto, cuando crea un tag, el conjunto de cambios en el cual este se almacena necesariamente se refiere a un conjunto de cambios anterior. Cuando ejecuta \hgcmdargs{clone}{-r foo} para clonar un repositorio hasta el tag -\texttt{foo}, el nuevo clon \emph{no contendrá la historia que creo +\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 la historia del proyecto en el +exactamente el subconjunto correcto de el historial del proyecto en el nuevo repositorio, pero, \emph{no} el tag que podría haber esperado. \subsection{Cuando las etiquetas permanentes son demasiado} Dado que las etiquetas de Mercurial están controladas por revisiones y se -llevan en la historia del proyecto, todas las personas involucradas +llevan en el historial del proyecto, todas las personas involucradas verán las etiquetas que usted haya creado. El hecho de dar nombres a las revisiones tiene usos más allá que simplemente hacer notar que la revisión \texttt{4237e45506ee} es realmente \texttt{v2.0.2}. Si está @@ -168,7 +168,7 @@ Para estos casos, lo que posiblemente desearía serían tags \emph{locales}. Puede crear un tag local con la opción \hgopt{tag}{-l} -de la orden \hgcmd{tag}. Esto guardará el tag en un archivo llamado +de la orden \hgcmd{tag}. Esto guardará el tag en un fichero llamado \sfilename{.hg/localtags}. A diferencia de \sfilename{.hgtags}, \sfilename{.hg/localtags} no está controlado por revisiones. Cualquier tag que usted cree usando \hgopt{tag}{-l} se mantendrá @@ -187,7 +187,7 @@ Usualmente la gente se refiere a esas direcciones concurrentes de desarrollo es como ``ramas''. Aunque hemos visto que -en variadas ocasiones Mercurial trata a \emph{toda la historia} como +en variadas ocasiones Mercurial trata a \emph{toda el historial} como una serie de ramas y fusiones. Realmente lo que tenemos aquí es dos ideas que se relacionan periféricamente, pero que en esencia comparten un nombre. @@ -246,7 +246,7 @@ facilidad; y es difícil cometer errores. Hay una relación uno a uno entre las ramas y los directorios con los que está trabajando en su sistema. Esto le permite usar emplear herramientas usuales(para los -nuevos a Mercurial) para trabajar con los archivos dentro de su +nuevos a Mercurial) para trabajar con los ficheros dentro de su rama/repositorio. Si se encuentra más en la categoría ``usuario diestro'' (\emph{y} sus @@ -291,8 +291,8 @@ la orden \hgcmd{branch}. ¿Qué reportan las ordenes \hgcmd{status} y \hgcmd{tip} commands report? \interaction{branch-named.status} -Nada cambia en el directorio actual, y no se ha añadido nada a la -historia. Esto sugiere que al ejecutar la orden \hgcmd{branch} no hay +Nada cambia en el directorio actual, y no se ha añadido nada al +historial. Esto sugiere que al ejecutar la orden \hgcmd{branch} no hay un efecto permanente; solamente le indica a que nombre de rama usará la \emph{próxima} vez que consigne un conjunto de cambios. @@ -336,7 +336,7 @@ Podemos hacer \hgcmd{update} entre los tipos de las ramas \texttt{foo} y \texttt{bar} sin necesidad de usar la opción \hgopt{update}{-C}, puesto que esto solamente implica ir linealmente hacia adelante y -atrás en nuestra historia de cambios. +atrás en nuestro historial de cambios. \interaction{branch-named.update-switchy} Si volvemos a la rama \texttt{foo} e invocamos la orden \hgcmd{update}, @@ -389,8 +389,8 @@ En el caso más sencillo, dar un nombre a cada rama ofrece un registro permanente acerca de en qué conjunto de cambios se generó la rama. -Esto le ofrece más contexto cuando esté tratando de seguir la -historia de un proyecto ramificado de larga vida. +Esto le ofrece más contexto cuando esté tratando de seguir el +historial de un proyecto ramificado de larga vida. Si está trabajando con repositorios compartidos, puede configurar el gancho \hook{pretxnchangegroup} para que cada uno bloquee los cambios con
--- a/es/cmdref.tex Sun Jan 18 21:01:13 2009 -0500 +++ b/es/cmdref.tex Sun Jan 18 21:37:11 2009 -0500 @@ -6,14 +6,14 @@ \optref{add}{X}{exclude} \optref{add}{n}{dry-run} -\cmdref{diff}{imprime los cambios en la historia o el directorio actual} +\cmdref{diff}{imprime los cambios en el historial o el directorio actual} Mostrar las diferencias entre revisiones para ficheros especificados o directorios, con el formato unificado diff. Si desea ver una descripción del formato unificado diff, ver la sección~\ref{sec:mq:patch}. De forma predeterminada, esta orden no imprime las diferencias para -los archivos binarios que Mercurial esté siguiendo. Para controlar +los ficheros binarios que Mercurial esté siguiendo. Para controlar este comportamiento, vea las opciones \hgopt{diff}{-a} y \hgopt{diff}{--git}.
--- a/es/collab.tex Sun Jan 18 21:01:13 2009 -0500 +++ b/es/collab.tex Sun Jan 18 21:37:11 2009 -0500 @@ -13,7 +13,7 @@ capacidades útiles. Para uso interactivo, la interfaz le permite visualizar uno o varios -repositorios. Puede ver la historia de un repositorio, examinar cada +repositorios. Puede ver el historial de un repositorio, examinar cada cambio(comentarios y diferencias), y ver los contenidos de cada directorio y fichero. @@ -49,7 +49,7 @@ CGI, como en la sección~\ref{sec:collab:cgi}. Publicar sobre HTTP satisface las necesidades de la gente que no tiene permisos de publicación y de aquellos que quieren usar navegadores web para -visualizar la historia del repositorio. +visualizar el historial del repositorio. \subsection{Trabajo con muchas ramas} @@ -270,7 +270,7 @@ La orden \hgcmd{serve} \emph{no} es un servidor web de propósito general. Solamente puede hacer dos cosas: \begin{itemize} -\item Permitir que se pueda visualizar la historia del repositorio que +\item Permitir que se pueda visualizar el historial del repositorio que está sirviendo desde navegadores web. \item Hablar el protocolo de conexión de Mercurial para que puedan hacer \hgcmd{clone} o \hgcmd{pull} (jalar) cambios de tal repositorio. @@ -520,7 +520,7 @@ este síntoma. \item El fichero de usuario \sfilename{authorized\_keys} puede tener un problema. Si alguien distinto al usuario es dueño o puede - escribir el archivo, el daemonio ssh no confiará o lo leerá. + escribir el fichero, el daemonio ssh no confiará o lo leerá. \end{itemize} En un mundo ideal, debería poder ejecutar la siguiente orden @@ -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 la historia de su repositorio. Uff! +una linda vista HTML de el historial de su repositorio. Uff! \subsubsection{Configuración de lighttpd} @@ -879,13 +879,13 @@ virtual \dirname{ruta/este/repo} en lugar de \dirname{este/repo}. El guión \sfilename{hgwebdir.cgi} buscará recursivamente en cada -directorio listado en la sección \texttt{collections} de su archivo de +directorio listado en la sección \texttt{collections} de su fichero de configuración, pero \texttt{no} hará el recorrido recursivo dentro de los repositorios que encuentre. El mecanismo de \texttt{collections} permite publicar fácilmente repositorios de una forma ``hacer y olvidar''. Solamente requiere -configurar el guión CGI y el archivo de configuración una vez. +configurar el guión CGI y el fichero de configuración una vez. Después de eso puede publicar y sacar de publicación un repositorio en cualquier momento incluyéndolo o excluyéndolo de la jerarquía de directorios en la cual le haya indicado a \sfilename{hgwebdir.cgi} que @@ -906,10 +906,10 @@ está en el lado derecho de cada definición, mientras que la ruta al repositorio está a la derecha. Note que no tiene que haber relación alguna entre la ruta virtual que elija y el lugar del repositorio en -su sistema de archivos. +su sistema de ficheros. Si lo desea, puede usar los dos mecanismos \texttt{collections} y -\texttt{paths} simultáneamente en un sólo archivo de configuración. +\texttt{paths} simultáneamente en un sólo fichero de configuración. \begin{note} Si varios repositorios tienen la misma ruta virtual, @@ -935,7 +935,7 @@ opciones de configuración para establecer. Todas ellas en la sección \rcsection{web}. \begin{itemize} -\item[\rcitem{web}{allow\_archive}] Determina cuáles tipos de archivos +\item[\rcitem{web}{allow\_archive}] Determina cuáles tipos de ficheros de descarga soportará Mercurial. Si habilita esta característica, los usuarios de la interfaz web podrán descargar una copia de la revisión del repositorio que estén viendo. Para activar la @@ -989,7 +989,7 @@ style = gitweb \end{codesample4} \item[\rcitem{web}{templates}] Ruta. Directorio en el que se buscarán - los archivos plantilla. De forma predeterminada, busca en el + los ficheros plantilla. De forma predeterminada, busca en el directorio en el cual fue instalado. \end{itemize} Si usa \sfilename{hgwebdir.cgi}, puede añadir otras opciones de
--- a/es/concepts.tex Sun Jan 18 21:01:13 2009 -0500 +++ b/es/concepts.tex Sun Jan 18 21:37:11 2009 -0500 @@ -563,7 +563,7 @@ Mercurial usar bloqueos para asegurarse de que sólo un proceso pueda escribir a un repositorio al mismo tiempo (el mecanismo de bloqueo es -seguro incluso sobre sistemas de archivos notoriamente hostiles al +seguro incluso sobre sistemas de ficheros notoriamente hostiles al bloqueo, como NFS). Si un repositorio está bloqueado, los escritores esperarán un buen rato para revisar si el repositorio ya ha sido desbloqueado, pero si el repositorio sique bloqueado por mucho tiempo,
--- a/es/daily.tex Sun Jan 18 21:01:13 2009 -0500 +++ b/es/daily.tex Sun Jan 18 21:37:11 2009 -0500 @@ -102,7 +102,7 @@ adicionado no está relacionado con el fichero anterior que tenía el mismo nombre. -\subsection{Al eliminar un fichero no se afecta su historia} +\subsection{Al eliminar un fichero no se afecta su historial} Es preciso tener en cuenta que al eliminar un fichero se tiene dos efectos solamente. @@ -112,8 +112,8 @@ \item Mercurial deja de hacer seguimiento a los cambios del fichero desde la próxima consignación. \end{itemize} -Al eliminar un fichero \emph{no} se altera de ninguna manera la -\emph{historia} del mismo. +Al eliminar un fichero \emph{no} se altera de ninguna manera el +\emph{historial} del mismo. Si actualiza su directorio de trabajo a un conjunto de cambios en el cual esl fichero que eliminó aún era tenido en cuenta, reaparecerá en
--- a/es/filenames.tex Sun Jan 18 21:01:13 2009 -0500 +++ b/es/filenames.tex Sun Jan 18 21:37:11 2009 -0500 @@ -200,7 +200,7 @@ cadena. Para buscar coincidencias en cualquier sitio dentro de una cadena, empiece su patrón con un ``\texttt{.*}''. -\section{Filtrado de archivos} +\section{Filtrado de ficheros} Mercurial no sólo le provee una variedad de formas para especificar ficheros; le permite limitar aún más dichos ficheros mediante el uso @@ -284,7 +284,7 @@ \subsection{Detección de conflictos de mayúsculas/minúsculas} Al operar en el directorio de trabajo, Mercurial respeta la política -de nombrado del sistema de archivos en que se encuentre el directorio +de nombrado del sistema de ficheros en que se encuentre el directorio de trabajo. Si el sistema de ficheros conserva las diferencias entre mayúsculas, pero no es sensible a ellas, Mercurial tratará los nombres que sólo difieren en mayúsculas como uno solo y el mismo.
--- a/es/hgext.tex Sun Jan 18 21:01:13 2009 -0500 +++ b/es/hgext.tex Sun Jan 18 21:37:11 2009 -0500 @@ -55,18 +55,18 @@ buen desempeño, los autores de Mercurial han optimizado este código en la medida de lo posible. Sin embargo, no puede obviarse el hecho de que cuando ejecuta \hgcmd{status}, Mercurial tendrá que hacer por lo -menos una costosa llamada al sistema por cada archivo administrado +menos una costosa llamada al sistema por cada fichero administrado para determinar si ha cambiado desde la última vez que se consignó. Para un repositorio suficientemente grande, puede tardar bastante tiempo. Para mostrar en números la magnitud de este efect, creé un repositorio -que contenía 150.000 archivos administrador. Tardó diez segundos para +que contenía 150.000 ficheros administrador. Tardó diez segundos para ejecutar \hgcmd{status}, a pesar de que \emph{ninguno} de los ficheros había sido modificado. Muchos sistemas operativos modernos contienen una facilidad de -notificación de archivos. Si un programa se registra con un servicio +notificación de ficheros. Si un programa se registra con un servicio apropiado, el sistema operativo le notificará siempre que un fichero de interés haya sido creado, modificado o borrado. En sistemas Linux, el componente del núcleo que lo hace se llama \texttt{inotify}.
--- a/es/intro.tex Sun Jan 18 21:01:13 2009 -0500 +++ b/es/intro.tex Sun Jan 18 21:37:11 2009 -0500 @@ -26,8 +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} - %TODO historia -\item Llevar registro de la historia y la evolución de su proyecto, para +\item Llevar registro de el 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. @@ -136,8 +135,7 @@ desarrollado la versión moderna de CVS. CVS adquirió posteriormente la habilidad de operar sobre una conexión de red, dotándolo de una arquitectura, cliente/servidor. La arquitectura de CVS es -%TODO historia/historial -centralizada; La historia del proyecto está únicamente en el +centralizada; el historial del proyecto está únicamente en el repositorio central. Los espacios de trabajo de los clientes contienen únicamente copias recientes de las versiones de los ficheros, y pocos metadatos para indicar dónde está el servidor. CVS @@ -147,9 +145,9 @@ 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 la -historia del proyecto. TeamWare no tiene la noción de repositorio -central. (CVS se basaba en RCS para el almacenamiento de su historia; +Un espacio de trabajo TeamWare contiene una copia completa de el +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.) A medida que avanzaba la decada de los noventa, se empezó a @@ -265,8 +263,7 @@ a trabajar en él, y ese proyecto usa una herramienta de control distribuido de revisiones, usted es de inmediato un par con la gente que se considera el ``alma'' del proyecto. Si ellos publican sus -%TODO historia/historial -repositorios, usted puede copiar inmediatamente la historia del proyecto, +repositorios, usted puede copiar inmediatamente el historial del proyecto, hacer cambios y guardar su trabajo, usando las mismas herramientas de la misma forma que ellos. En contraste, con una herramienta centralizada, usted debe usar el programa en un modo ``sólo lectura'' a @@ -289,10 +286,8 @@ En algunas ocasiones los líderes de las bifurcaciones reconcilian sus diferencias. Con un sistema centralizado de control de revisiones, el proceso \emph{técnico} de reconciliarse es doloroso, y se hace de -%TODO historia/historial -forma muy manual. Usted tiene que decidir qué historia de revisiones va a +forma muy manual. Usted tiene que decidir qué historial de revisiones va a ``ganar'', e injertar los cambios del otro equipo en el árbol de alguna -%TODO historia/historial manera. Con esto usualmente se pierde algo o todo del historial de la revisión de alguna de las partes. @@ -323,11 +318,11 @@ desean mantener control completo sobre sus proyectos, y creen que las herramientas centralizadas les dan tal control. En todo caso, si este es su parecer, y usted publica sus repositorios de CVS o Subversion, hay -muchas herramientas disponibles que pueden obtener la historia -completa (aunque sea lentamente) y recrearla en otro sitio que usted no +muchas herramientas disponibles que pueden obtener el historial +completo (aunque sea lentamente) y recrearlo en otro sitio que usted no controla. Siendo así un control ilusorio, puesto que está impidiendo la fluidez de colaboración en lugar de prevenir que alguien se sienta -impulsado a obtener una copia y hacer una bifurcación con su historia. +impulsado a obtener una copia y hacer una bifurcación con su historial. \subsection{Ventajas para proyectos comerciales} @@ -357,8 +352,8 @@ sistema distribuido de control de versiones al resolver problemas en el sitio del cliente. La herramienta le permitirá generar construcciones a la medida, probar diferentes arreglos de forma -independiente y buscar de forma eficiente las fuentes de fallos en la -historia y regresiones en los ambientes de los clientes, todo sin +independiente y buscar de forma eficiente las fuentes de fallos en el +historial y regresiones en los ambientes de los clientes, todo sin necesidad de conectarse al servidor de su compañía. \section{¿Por qué elegir Mercurial?} @@ -382,8 +377,8 @@ En un proyecto pequeño, usted puede comenzar a trabajar con Mercurial en pocos momentos. Crear nuevos cambios y ramas, transferir cambios (localmente -o por la red); y las operaciones relacionadas con el estado y la -historia son rápidas. Mercurial buscar ser ligero y no incomodar en su +o por la red); y las operaciones relacionadas con el estado y el +historial son rápidas. Mercurial buscar ser ligero y no incomodar en su camino combinando poca sobrecarga cognitiva con operaciones asombrosamente rápidas. @@ -444,8 +439,8 @@ información frente a la revisión actual (\texttt{diff}). Como resultado, la copia de trabajo de Subversion termina siendo del mismo tamaño o más grande que un repositorio de Mercurial y el directorio de -trabajo, a pesar de que el repositorio de Mercurial contiene la -historia completa del proyecto. +trabajo, a pesar de que el repositorio de Mercurial contiene el +historial completo del proyecto. Subversion tiene soporte amplio de otras herramientas. Mercurial por ahora está bastante atrás en este aspecto. Esta diferencia está @@ -453,7 +448,7 @@ Usuario Gráfica}, eclipsan sus equivalentes de Subversion. Al igual que Mercurial, Subversion tiene un excelente manual de usuario. -Dado que Subversion no almacena la historia de revisiones en el +Dado que Subversion no almacena el historial de revisiones en el cliente, es muy bueno para administrar proyectos que tienen muchos ficheros binarios grandes y opacos. Si consigna cincuenta revisiones de un fichero de 10MB que no es comprimible, el esapacio en el cliente @@ -469,11 +464,11 @@ ventaja significativa en un proyecto donde los ficheros binarios sean usados ampliamente. -Mercurial puede importar la historia de revisiones de un repositorio -de Subversion. También puede exportar historia de revisiones a un +Mercurial puede importar el historial de revisiones de un repositorio +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 la historia es incremental, de modo +a dar el paso. La conversión de el 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. @@ -528,8 +523,7 @@ consignar exitósamente parte del cambio y estar bloqueada por la necesidad de una mezcla, forzando a otras personas a ver solamente una porción del trabajo que estaban buscando hacer. Esto afecta también -%TODO historia/historial -la forma como usted trabaja con la historia del proyecto. Si quiere +la forma como usted trabaja con el historial del proyecto. Si quiere ver todas las modificaciones que alguien hizo como parte de una tarea, necesitará inspeccionar manualmente las descripciones y las marcas de tiempo de cambio de cada fichero involucrado (esto, si usted saber @@ -543,12 +537,12 @@ repositorio. Yo no recomendaría un repositorio de CVS para proyecto alguno, ni existente ni nuevo. -Mercurial puede importar la historia de revisiones de CVS. De todas +Mercurial puede importar el historial de revisiones de CVS. De todas maneras hay ciertas precauciones que aplican; las cuales también son necesarias para cualquier herramienta importadora de historial de CVS. Debido a la falta de atomicidad de cambios y el no versionamiento de la jerarquía del sistema de ficheros, es imposible reconstruir -completamente la historia de CVS con precisión; hay cierto trabajo de +completamente el historial de CVS con precisión; hay cierto trabajo de conjetura involucrado y los renombramientos tampoco se mostrarán. Debido a que gran parte de la administración avanzada de CVS tiene que hacerse manualmente y por lo tanto es proclive al error, @@ -558,8 +552,7 @@ dos de los problemas menos interesantes de los que puedo retomar de mi experiencia personal). -%TODO historia/historial -Mercurial puede importar la historia de revisiones de un repositorio +Mercurial puede importar el historial de revisiones de un repositorio CVS. \subsection{Herramientas comerciales} @@ -596,7 +589,7 @@ Mercurial viene con una extensión llamada \hgext{convert}, que puede importar historiales de revisiones de forma incremental desde varias herramientas de control de revisiones. Por ``incremental'', quiero -decir que puede migrar toda la historia de un proyecto en una primera +decir que puede migrar toda el historial de un proyecto en una primera instancia y después volver a ejecutar la migración posteriormente para obtener los nuevos cambios que han sucedido después de la migración inicial.
--- a/es/mq-collab.tex Sun Jan 18 21:01:13 2009 -0500 +++ b/es/mq-collab.tex Sun Jan 18 21:37:11 2009 -0500 @@ -351,13 +351,13 @@ tiene problemas manejando nombres de parches que contienen separadores de ruta. -\subsection{Ver la historia de un parche} +\subsection{Ver el historial de un parche} \label{mq-collab:tips:interdiff} Si usted está desarrollando un conjunto de parches en un período de tiempo grande, es una buena idea mantenerlos en un repositorio, como se discutió en la sección~\ref{sec:mq:repo}. Si lo hace, notará -rápidamente que usar el comando \hgcmd{diff} para mirar la historia +rápidamente que usar el comando \hgcmd{diff} para mirar el historial del repositorio no es viable. Esto es debido en parte a que usted está mirando la segunda derivada del código real (el diff de un diff), pero también porque MQ añade ruido al proceso al modificar las marcas de
--- a/es/mq-ref.tex Sun Jan 18 21:01:13 2009 -0500 +++ b/es/mq-ref.tex Sun Jan 18 21:37:11 2009 -0500 @@ -257,7 +257,7 @@ el nuevo conjunto de cambios que representa el parche. \item Las modificaciones a los ficheros a los que se les da seguimiento en el directorio de trabajo se añade al parche. -\item Los cambios a los archivos a los que se les da seguimiento con +\item Los cambios a los ficheros a los que se les da seguimiento con \hgcmd{add}, \hgcmd{copy}, \hgcmd{remove}, o \hgcmd{rename}. Se añaden al parche los ficheros añadidos, copiados y renombrados, mientras que los ficheros eliminados y las fuentes renombradas se
--- a/es/mq.tex Sun Jan 18 21:01:13 2009 -0500 +++ b/es/mq.tex Sun Jan 18 21:37:11 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 la historia de revisiones normales, y +Sus parches viven encima de el 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
--- a/es/template.tex Sun Jan 18 21:01:13 2009 -0500 +++ b/es/template.tex Sun Jan 18 21:37:11 2009 -0500 @@ -485,7 +485,7 @@ Podríamos haber incluído el texto del fichero plantilla directamente en el fichero de estilo encerrando entre comillas y reemplazando las nuevas líneas con secuencias ``\verb!\n!'', pero haría muy difícil de -leer el archivo de estilos. La facilidad para leer es importante +leer el fichero de estilos. La facilidad para leer es importante cuando está decidiendo si un texto pertenece a un fichero de estilo o a un fichero de plantilla incluído en el estilo. Si el fichero de estilo luce muy grande o complicado, si inserta una pieza de texto
--- a/es/tour-basic.tex Sun Jan 18 21:01:13 2009 -0500 +++ b/es/tour-basic.tex Sun Jan 18 21:37:11 2009 -0500 @@ -144,7 +144,7 @@ repositorio y en el repositorio que clonamos. Cada repositorio Mercurial está completo, es autocontenido e -independiente. Contiene su propia copia de los ficheros y la historia +independiente. Contiene su propia copia de los ficheros y el historial de un proyecto. Un repositorio clonado recuerda la ubicación de la que fue clonado, pero no se comunica con ese repositorio, ni con ningún otro, a menos que usted le indique que lo haga. @@ -169,7 +169,6 @@ el repositorio ``real'', y todos los ficheros y directorios que coexisten con él están en el \emph{directorio de trabajo}. Una forma sencilla de recordar esta distinción es que el \emph{repositorio} -% TODO unificar con Igor, si historia o historial contiene el \emph{historial} de su proyecto, mientras que el \emph{directorio de trabajo} contiene una \emph{instantánea} de su proyecto en un punto particular del historial.
--- a/es/tour-merge.tex Sun Jan 18 21:01:13 2009 -0500 +++ b/es/tour-merge.tex Sun Jan 18 21:37:11 2009 -0500 @@ -164,7 +164,7 @@ \command{kdiff3} ejecutándose, en la figura~\ref{fig:tour-merge:kdiff3}. El tipo de fusión que la herramienta hace se conoce como \emph{fusión de tres vías}, porque hay -tres versiones diferentes del archivo en que estamos interesados. +tres versiones diferentes del fichero en que estamos interesados. Debido a esto la herramienta divide la parte superior de la ventana en tres paneles. \begin{itemize} @@ -204,7 +204,7 @@ diferencian en las plataformas para las que están disponibles, y en sus fortalezas y debilidades particulares. La mayoría están afinadas para fusionar texto plano, mientras que otras están pensadas para -formatos de archivos especializados (generalmente XML). +formatos de ficheros especializados (generalmente XML). % TODO traduje "worked" como "real" \subsection{Un ejemplo real}
--- a/es/undo.tex Sun Jan 18 21:01:13 2009 -0500 +++ b/es/undo.tex Sun Jan 18 21:37:11 2009 -0500 @@ -8,7 +8,7 @@ tiene unas características poderosas que le ayudarán a isolar las fuentes de los problemas, y a dar cuenta de ellas apropiadamente. -\section{Borrar la historia local} +\section{Borrar el historial local} \subsection{La consignación accidental} @@ -51,7 +51,7 @@ el conjunto de cambios. Uso la orden \hgcmd{rollback}, y Mercurial hace desaparecer el último conjunto de cambios. \interaction{rollback.rollback} -El conjunto de cambios ya no está en la historia del repositorio, y el +El conjunto de cambios ya no está en el historial del repositorio, y el directorio de trabajo cree que el fichero \filename{a} ha sido modificado. La consignación y el roll back dejaron el directorio de trabajo exactamente como estaba antes de la consignación; el conjunto @@ -88,7 +88,7 @@ El valor de \hgcmd{rollback} se anula cuando ha publicado sus cambios a otro repositorio. Un cambio desaparece totalmente al hacer roll back, pero \emph{solamente} en el repositorio en el cual aplica -\hgcmd{rollback}. Debido a que un roll back elimina la historia, +\hgcmd{rollback}. Debido a que un roll back elimina el historial, no hay forma de que la desaparición de un cambio se propague entre repositorios. @@ -220,7 +220,7 @@ parte de un conjunto de cambios a mano. Antes de leer esta sección, hay algo para tener en cuenta: la orden -\hgcmd{backout} deshace cambios \emph{adicionando} a la historia, sin +\hgcmd{backout} deshace cambios \emph{adicionando} a el historial, sin modificar o borrar. Es la herramienta correcta si está arreglando fallos, pero no si está tratando de deshacer algún cambio que tiene consecuencias catastróficas. Para tratar con esos, vea la sección~\ref{sec:undo:aaaiiieee}. @@ -228,7 +228,7 @@ \subsection{Retroceder un conjunto de cambios} La orden \hgcmd{backout} le permite ``deshacer'' los efectos de todo -un conjunto de cambios de forma automatizada. Dado que la historia de +un conjunto de cambios de forma automatizada. Dado que el historial de Mercurial es inmutable, esta orden \emph{no} se deshace del conjunto de cambios que usted desea deshacer. En cambio, crea un nuevo conjunto de cambios que \emph{reversa} el conjunto de cambios que @@ -257,8 +257,8 @@ 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 la historia de cambios. Como puede ver, la historia es -bonita y lineal. +gráfica de el historial de cambios. Como puede ver, el historial es +bonito y lineal. \begin{figure}[htb] \centering @@ -281,7 +281,7 @@ presentes, pero no el segundo. \interaction{backout.non-tip.cat} -Como lo muestra la historia gráfica en la +Como lo muestra el historial gráfico en la figura~\ref{fig:undo:backout-non-tip}, Mercurial realmente consigna \emph{dos} cambios en estas situaciones (los nodos encerrados en una caja son aquellos que Mercurial consigna automaticamente). Antes de @@ -301,7 +301,7 @@ \end{figure} El resultado es que usted termina ``donde estaba'', solamente con un -poco de historia adicional que deshace el efecto de un conjunto de +poco de historial adicional que deshace el efecto de un conjunto de cambios que usted quería evitar. \subsubsection{Use siempre la opción \hgopt{backout}{--merge}} @@ -333,8 +333,8 @@ orden \hgcmd{backout} fue muy explícita diciéndolo. \interaction{backout.manual.log} -De nuevo, es más sencillo lo que pasó viendo una gráfica de la -historia de revisiones, en la figura~\ref{fig:undo:backout-manual}. +De nuevo, es más sencillo lo que pasó viendo una gráfica del +historial de revisiones, en la figura~\ref{fig:undo:backout-manual}. Esto nos aclara que cuando usamos \hgcmd{backout} para retroceder un cambio a algo que no sea la punta, Mercurial añade una nueva cabeza al repositorio (el cambio que consignó está encerrado en una caja). @@ -355,14 +355,14 @@ 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 la historia +puesto que es el que retrocedimos. Dado que la gráfica de el 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} Para que el tercer cambio esté en el fichero, hacemos una fusión usual de las dos cabezas. \interaction{backout.manual.merge} -Después de eso, la historia gráfica de nuestro repositorio luce como +Después de eso, el historial gráfica de nuestro repositorio luce como la figura~\ref{fig:undo:backout-manual-merge}. \begin{figure}[htb] @@ -411,7 +411,7 @@ retrocediendo y la punta actual. Si está retrocediendo un conjunto de cambios que está a unas ~100 -atrás en su historia del proyecto, las posibilidades de que una orden +atrás en su historial del proyecto, las posibilidades de que una orden \command{patch} sea capaz de ser aplicada a un diff reverso, claramente no son altas, porque los cambios que intervienen podrían ``no coincidir con el contexto'' que \command{patch} usa para @@ -442,13 +442,13 @@ colocarse una bolsa de papel desechable en su cabeza), permítame discutir primero unas aproximaciones que probablemente no funcionen. -Dado que Mercurial trata de forma acumulativa la historia---cada -cambio se coloca encima de todos los cambios que leo -preceden---usualmente usted no puede hacer que unos cambios desastros +Dado que Mercurial trata de forma acumulativa al historial---cada +cambio se coloca encima de todos los cambios que le +preceden---usualmente usted no puede hacer que unos cambios desastrosos desaparezcan. La única excepción es cuando usted ha acabado de consignar un cambio y este no ha sido publicado o jalado en otro repositorio. Ahí es cuando puede usar la orden \hgcmd{rollback} con -seguridad, Como detallé en la sección~\ref{sec:undo:rollback}. +seguridad, como detallé en la sección~\ref{sec:undo:rollback}. Después de que usted haya publicado un cambio en otro repositorio, usted \emph{podría} usar la orden \hgcmd{rollback} para hacer que en su copia @@ -466,7 +466,7 @@ Si ha consignado uno o más cambios \emph{después} del cambio que desea desaparecer, sus opciones son aún más reducidas. Mercurial no provee -una forma de ``cabar un hueco'' en la historia, dejando los conjuntos +una forma de ``cabar un hueco'' en el historial, dejando los conjuntos de cambios intactos. %Dejamos de traducir lo que viene a continuación, porque será @@ -561,20 +561,20 @@ búsqueda a ellos, estaría tomabdi más de 40 horas para encontrar al conjunto de cambios culpable. -La orden \hgcmd{bisect} usa su conocimiento de la ``forma'' de la -historia de revisiones de su proyecto para hacer una búsqueda +La orden \hgcmd{bisect} usa su conocimiento de la ``forma'' del +historial de revisiones de su proyecto para hacer una búsqueda proporcional al \emph{logaritmo} del número de conjunto de cambios a -revisar( el tipo de búsqueda que realiza se llama búsqueda +revisar (el tipo de búsqueda que realiza se llama búsqueda binaria). Con esta aproximación, el buscar entre 10.000 conjuntos de -cambios tomará menos de 3 horas, incluso a diez minutos por prueba(La +cambios tomará menos de 3 horas, incluso a diez minutos por prueba (La búsqueda requerirá cerca de 14 pruebas). Al limitar la búsqueda a la última centena de conjuntos de cambios, tomará a lo sumo una -hora(Apenas unas 7 pruebas). +hora (Apenas unas 7 pruebas). La orden \hgcmd{bisect} tiene en cuenta la naturaleza ``ramificada'' -de la historia de revisiones del proyecto con Mercurial, así que no +de el 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 historia con un solo +repositorio. Puede evitar ramas enteras de historial con un solo sondeo. \subsection{Uso de la orden \hgcmd{bisect}} @@ -790,7 +790,7 @@ otro fallo puede enmascararlo(como se discutió anteriormente). Incluso si termina ``muy atrás'' por miles de conjuntos de cambios o -meses de historia, solamente estaŕa adicionando unas pruebas contadas +meses de historial, solamente estaŕa adicionando unas pruebas contadas para \hgcmd{bisect}, gracias al comportamiento logarítmico. %%% Local Variables: