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.