comparison es/intro.tex @ 609:98fb436b58c1

corrected some typos

608:e98a8c3afcef

El control de revisiones es un campo amplio, tan amplio que no hay un
acrónimo o nombre único. A continuación presentamos un listado de
nombres comunes y acrónimos que se podrían encontrar:
\begin{itemize}
\item Control de revisiones (RCS)
\item Manejo de Configuraciones de Programas(SCM), o administracón de
  configuraciones
\item Administración de código fuente
\item Control de Código Fuente, o Control de Fuentes
\item Control de Versiones(VCS)
\end{itemize}
Algunas personas aducen que estos términos tienen significados
diversos, pero en la práctica se sobrelapan tanto que no hay una
forma acordada o incluso adecuada de separarlos.

\section{Historia resumida del control de revisiones}

La herramienta de control de revisiones más antigua conocida es SCCS 
(Sistema de Control de Código), escrito por Marc Rochkind en Bell
Labs, a comienzos de los setentas(1970s).  SCCS operaba sobre ficheros
individuales, y requería que cada persona que trabajara en el proyecto
tuviera acceso a un espacio compartido en un solo sistema.  Solamente
una persona podía modificar un fichero en un momento dado; el
arbitramiento del acceso a los ficheros se hacía con candados. Era
común que la gente pusiera los candados a los ficheros, y que
posteriormente olvidara quitarlos, impidiendo que otro pudiera
modificar los ficheros en cuestión sin la intervención del
administrador.

Walter Tichy desarrolló una alternativa gratuita a SCCS a comienzos
de los ochentas(1980s); llamó a su programa RCS (Sistema de Control de
Revisiones).  Al igual que SCCS, RCS requería que los desarrolladores
trabajaran en un único espacio compartido y colocaran candados a los
ficheros para evitar que varias personas los modificaran
simultáneamente.

para proyectos modestamente grandes.

Adicionalmente, Subversion tiene un sobrecosto considerable en
almacenamiento para evitar transacciones por red en algunas
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.

609:98fb436b58c1

El control de revisiones es un campo amplio, tan amplio que no hay un
acrónimo o nombre único. A continuación presentamos un listado de
nombres comunes y acrónimos que se podrían encontrar:
\begin{itemize}
\item Control de revisiones (RCS)
\item Manejo de Configuraciones de Programas (SCM), o administracón de
  configuraciones
\item Administración de código fuente
\item Control de Código Fuente, o Control de Fuentes
\item Control de Versiones (VCS)
\end{itemize}
Algunas personas aducen que estos términos tienen significados
diversos, pero en la práctica se sobrelapan tanto que no hay una
forma acordada o incluso adecuada de separarlos.

\section{Historia resumida del control de revisiones}

La herramienta de control de revisiones más antigua conocida es SCCS 
(Sistema de Control de Código), escrito por Marc Rochkind en Bell
Labs, a comienzos de los setentas (1970s).  SCCS operaba sobre ficheros
individuales, y requería que cada persona que trabajara en el proyecto
tuviera acceso a un espacio compartido en un solo sistema.  Solamente
una persona podía modificar un fichero en un momento dado; el
arbitramiento del acceso a los ficheros se hacía con candados. Era
común que la gente pusiera los candados a los ficheros, y que
posteriormente olvidara quitarlos, impidiendo que otro pudiera
modificar los ficheros en cuestión sin la intervención del
administrador.

Walter Tichy desarrolló una alternativa gratuita a SCCS a comienzos
de los ochentas (1980s); llamó a su programa RCS (Sistema de Control de
Revisiones).  Al igual que SCCS, RCS requería que los desarrolladores
trabajaran en un único espacio compartido y colocaran candados a los
ficheros para evitar que varias personas los modificaran
simultáneamente.

para proyectos modestamente grandes.

Adicionalmente, Subversion tiene un sobrecosto considerable en
almacenamiento para evitar transacciones por red en algunas
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.