comparison es/intro.tex @ 615:9da096de3c52

changed "historia" to "historial". changed "archivo" to "fichero" corrected some typos

614:aa01d35ac59f

\subsection{¿Por qué usar control de revisiones?}

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
  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.
\item Cuando trabaja con más personas, los programas de control de
  revisiones facilitan la colaboración.  Por ejemplo, cuando varias

Brian Berliner tomó los scripts originales de Grune y los reescribió
en~C, publicando en 1989 el código sobre el cual se ha
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
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
ha tenido un éxito enorme; Es probablemente el sistema de control de
revisiones más extendido del planeta.

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;
TeamWare usaba SCCS.)

A medida que avanzaba la decada de los noventa, se empezó a
evidenciar los problemas de CVS.  Almacena cambios simultáneos a muchos
ficheros de forma individual, en lugar de agruparlos como una

Si descubre un proyecto de código abierto y decide que desea comenzar
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,
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
menos que alguien le otorgue permisos para consignar cambios en el
repositorio central. Hasta entonces, no podrá almacenar sus cambios y

proyecto y toma su propio rumbo.

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
``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.

Lo que las herramientas distribuidas hacen con respecto a las
bifurcaciones, es que las bifurcaciones son la \emph{única} forma de

Algunas personas se resisten a las herramientas distribuidas porque
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
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.

\subsection{Ventajas para proyectos comerciales}

Muchos proyectos comerciales tienen grupos de trabajo distribuidos
alrededor del globo.  Quienes contribuyen y están lejos de un

Si tiene un empleado en el campo, se beneficiará grandemente de un
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
necesidad de conectarse al servidor de su compañía.

\section{¿Por qué elegir Mercurial?}

Mercurial cuenta con un conjunto único de propiedades que lo hacen

con que siga unas pocas reglas generales en lugar de un montón de
excepciones.

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
camino combinando poca sobrecarga cognitiva con operaciones
asombrosamente rápidas.

La utilidad de Mercurial no se limita a proyectos pequeños: está
siendo usado por proyectos con centenas de miles de contribuyentes,

operaciones,
tales como encontrar ficheros modificados (\texttt{status}) y desplegar
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.

Subversion tiene soporte amplio de otras herramientas. Mercurial por
ahora está bastante atrás en este aspecto.  Esta diferencia está
disminuyendo, y algunas de las herramientas GUI\ndt{Interfaz de
  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
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
de Subversion se mantendrá constante mientras que el espacio usado por
cualquier Sistema Distribuido de Control de Revisiones crecerá

para permitirle al usuario poner una cerradura  a un fichero, de modo
que tenga un permiso exclusivo para consignar cambios, puede ser una
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
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
que puede aplicar una conversión inicial, y después conversiones
pequeñas y adicionales posteriormente para traer nuevos cambios.

\subsection{Git}

cambios relacionados en consignaciones atómicas, pemitiendo que con
facilidad la gente ``rompa la construcción'': una persona puede
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
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
cuáles eran tales ficheros).

repositorio. Casi no tiene chequeo de consistencia interna, por lo
tanto es casi imposible identificar por que o cómo se corrompió un
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
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
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,
es común que los importadores de CVS encuentren muchos problemas con
repositorios corruptos (marcas de tiempo totalmente desubicadas y
ficheros que han permanecido con candados por más de una década son
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
CVS.

\subsection{Herramientas comerciales}

Perforce tiene una arquitectura centralizada cliente/servidor sin

\section{Migrar de otra herramienta hacia Mercurial}

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
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 continuación presentamos las herramientas de revisiones que soporta

615:9da096de3c52

\subsection{¿Por qué usar control de revisiones?}

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
  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.
\item Cuando trabaja con más personas, los programas de control de
  revisiones facilitan la colaboración.  Por ejemplo, cuando varias

Brian Berliner tomó los scripts originales de Grune y los reescribió
en~C, publicando en 1989 el código sobre el cual se ha
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
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
ha tenido un éxito enorme; Es probablemente el sistema de control de
revisiones más extendido del planeta.

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
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
evidenciar los problemas de CVS.  Almacena cambios simultáneos a muchos
ficheros de forma individual, en lugar de agruparlos como una

Si descubre un proyecto de código abierto y decide que desea comenzar
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
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
menos que alguien le otorgue permisos para consignar cambios en el
repositorio central. Hasta entonces, no podrá almacenar sus cambios y

proyecto y toma su propio rumbo.

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
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
manera. Con esto usualmente se pierde algo o todo del historial de la
revisión de alguna de las partes.

Lo que las herramientas distribuidas hacen con respecto a las
bifurcaciones, es que las bifurcaciones son la \emph{única} forma de

Algunas personas se resisten a las herramientas distribuidas porque
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 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 historial.

\subsection{Ventajas para proyectos comerciales}

Muchos proyectos comerciales tienen grupos de trabajo distribuidos
alrededor del globo.  Quienes contribuyen y están lejos de un

Si tiene un empleado en el campo, se beneficiará grandemente de un
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 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?}

Mercurial cuenta con un conjunto único de propiedades que lo hacen

con que siga unas pocas reglas generales en lugar de un montón de
excepciones.

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 el
historial son rápidas. Mercurial buscar ser ligero y no incomodar en su
camino combinando poca sobrecarga cognitiva con operaciones
asombrosamente rápidas.

La utilidad de Mercurial no se limita a proyectos pequeños: está
siendo usado por proyectos con centenas de miles de contribuyentes,

operaciones,
tales como encontrar ficheros modificados (\texttt{status}) y desplegar
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 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á
disminuyendo, y algunas de las herramientas GUI\ndt{Interfaz de
  Usuario Gráfica}, eclipsan sus equivalentes de Subversion. Al igual
que Mercurial, Subversion tiene un excelente manual de usuario.

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
de Subversion se mantendrá constante mientras que el espacio usado por
cualquier Sistema Distribuido de Control de Revisiones crecerá

para permitirle al usuario poner una cerradura  a un fichero, de modo
que tenga un permiso exclusivo para consignar cambios, puede ser una
ventaja significativa en un proyecto donde los ficheros binarios sean
usados ampliamente.

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 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.

\subsection{Git}

cambios relacionados en consignaciones atómicas, pemitiendo que con
facilidad la gente ``rompa la construcción'': una persona puede
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
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
cuáles eran tales ficheros).

repositorio. Casi no tiene chequeo de consistencia interna, por lo
tanto es casi imposible identificar por que o cómo se corrompió un
repositorio. Yo no recomendaría un repositorio de CVS para proyecto
alguno, ni existente ni nuevo.

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 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,
es común que los importadores de CVS encuentren muchos problemas con
repositorios corruptos (marcas de tiempo totalmente desubicadas y
ficheros que han permanecido con candados por más de una década son
dos de los problemas menos interesantes de los que puedo retomar de mi
experiencia personal).

Mercurial puede importar el historial de revisiones de un repositorio
CVS.

\subsection{Herramientas comerciales}

Perforce tiene una arquitectura centralizada cliente/servidor sin

\section{Migrar de otra herramienta hacia Mercurial}

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 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 continuación presentamos las herramientas de revisiones que soporta