Mercurial > hgbook
diff es/intro.tex @ 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 | 98fb436b58c1 |
children | 3f32047a3f25 |
line wrap: on
line diff
--- 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.