1.1 --- a/es/intro.tex	Fri Nov 07 21:42:57 2008 -0500
     1.2 +++ b/es/intro.tex	Sat Nov 08 19:31:13 2008 -0500
     1.3 @@ -1,130 +1,145 @@
     1.4 -\chapter{Introduction}
     1.5 +\chapter{Introducción}
     1.6  \label{chap:intro}
     1.7  
     1.8 -\section{About revision control}
     1.9 -
    1.10 -Revision control is the process of managing multiple versions of a
    1.11 -piece of information.  In its simplest form, this is something that
    1.12 -many people do by hand: every time you modify a file, save it under a
    1.13 -new name that contains a number, each one higher than the number of
    1.14 -the preceding version.
    1.15 -
    1.16 -Manually managing multiple versions of even a single file is an
    1.17 -error-prone task, though, so software tools to help automate this
    1.18 -process have long been available.  The earliest automated revision
    1.19 -control tools were intended to help a single user to manage revisions
    1.20 -of a single file.  Over the past few decades, the scope of revision
    1.21 -control tools has expanded greatly; they now manage multiple files,
    1.22 -and help multiple people to work together.  The best modern revision
    1.23 -control tools have no problem coping with thousands of people working
    1.24 -together on projects that consist of hundreds of thousands of files.
    1.25 -
    1.26 -\subsection{Why use revision control?}
    1.27 -
    1.28 -There are a number of reasons why you or your team might want to use
    1.29 -an automated revision control tool for a project.
    1.30 +\section{Acerca del control de revisiones}
    1.31 +
    1.32 +El control de revisiones es el proceso de administrar diferentes
    1.33 +versiones de una pieza de información. En su forma más simple es algo
    1.34 +que la mayoría de gente hace a mano: cada vez que usted modifica un
    1.35 +fichero, lo graba con un nuevo nombre que contiene un número, el
    1.36 +siguiente mayor que el anterior.
    1.37 +
    1.38 +Administrar manualmente muchas versiones de un fichero es una tarea
    1.39 +propensa a errores, a pesar de que hace bastante tiempo hay
    1.40 +herramientas que ayudan en este proceso.  Las primeras herramientas
    1.41 +para automatizar el control de revisiones fueron pensadas para que un
    1.42 +usuario administrara un solo fichero.  En las décadas pasadas, el
    1.43 +alcance de las herramientas de control de revisiones ha ido aumentando
    1.44 +considerablemente; ahora manejan muchos archivos y facilitan el
    1.45 +trabajo en conjunto de varias personas. Las mejores herramientas de
    1.46 +control de revisiones de la actualidad no tienen problema con miles de
    1.47 +personas trabajando en proyectos que consisten de decenas de miles de
    1.48 +ficheros.
    1.49 +
    1.50 +\subsection{¿Por qué usar control de revisiones?}
    1.51 +
    1.52 +Hay muchas razones por las cuales usted o su equipo desearía usar una
    1.53 +herramienta automática de control de revisiones para un proyecto.
    1.54  \begin{itemize}
    1.55 -\item It will track the history and evolution of your project, so you
    1.56 -  don't have to.  For every change, you'll have a log of \emph{who}
    1.57 -  made it; \emph{why} they made it; \emph{when} they made it; and
    1.58 -  \emph{what} the change was.
    1.59 -\item When you're working with other people, revision control software
    1.60 -  makes it easier for you to collaborate.  For example, when people
    1.61 -  more or less simultaneously make potentially incompatible changes,
    1.62 -  the software will help you to identify and resolve those conflicts.
    1.63 -\item It can help you to recover from mistakes.  If you make a change
    1.64 -  that later turns out to be in error, you can revert to an earlier
    1.65 -  version of one or more files.  In fact, a \emph{really} good
    1.66 -  revision control tool will even help you to efficiently figure out
    1.67 -  exactly when a problem was introduced (see
    1.68 -  section~\ref{sec:undo:bisect} for details).
    1.69 -\item It will help you to work simultaneously on, and manage the drift
    1.70 -  between, multiple versions of your project.
    1.71 +\item Contar con la historia y la evolución de su proyecto, para
    1.72 +  evitar hacer la tarea manualmente. Por cada cambio tendrá una
    1.73 +  bitácora de \emph{quién} lo hizo; \emph{por qué} se hizo;
    1.74 +  \emph{cuándo} se hizo; y de \emph{qué} se trataba el cambio.
    1.75 +\item Cuando trabaja con más personas, los programas de control de
    1.76 +  revisiones facilitan la colaboración.  Por ejemplo, cuando varias
    1.77 +  personas de forma casi simultanea pueden hacer cambios
    1.78 +  incompatibles, el programa le ayudará a identificar y resolver tales
    1.79 +  conflictos.
    1.80 +\item Puede ayudarle a recuperarse de equivocaciones. Si aplica un
    1.81 +  cambio que posteriormente se evidencia como un error, puede
    1.82 +  revertirlo a una versión previa a uno o muchos ficheros. De hecho,
    1.83 +  una herramienta \emph{realmente} buena, incluso puede ayudarle
    1.84 +  efectivamente a darse cuenta exactamente cuándo se introdujo el
    1.85 +  error( para más detalles ver la sección~\ref{sec:undo:bisect}).
    1.86 +\item Le permitirá trabajar simultáneamente, y manejar las diferencias
    1.87 +  entre múltiples versiones de su proyecto.
    1.88  \end{itemize}
    1.89 -Most of these reasons are equally valid---at least in theory---whether
    1.90 -you're working on a project by yourself, or with a hundred other
    1.91 -people.
    1.92 -
    1.93 -A key question about the practicality of revision control at these two
    1.94 -different scales (``lone hacker'' and ``huge team'') is how its
    1.95 -\emph{benefits} compare to its \emph{costs}.  A revision control tool
    1.96 -that's difficult to understand or use is going to impose a high cost.
    1.97 -
    1.98 -A five-hundred-person project is likely to collapse under its own
    1.99 -weight almost immediately without a revision control tool and process.
   1.100 -In this case, the cost of using revision control might hardly seem
   1.101 -worth considering, since \emph{without} it, failure is almost
   1.102 -guaranteed.
   1.103 -
   1.104 -On the other hand, a one-person ``quick hack'' might seem like a poor
   1.105 -place to use a revision control tool, because surely the cost of using
   1.106 -one must be close to the overall cost of the project.  Right?
   1.107 -
   1.108 -Mercurial uniquely supports \emph{both} of these scales of
   1.109 -development.  You can learn the basics in just a few minutes, and due
   1.110 -to its low overhead, you can apply revision control to the smallest of
   1.111 -projects with ease.  Its simplicity means you won't have a lot of
   1.112 -abstruse concepts or command sequences competing for mental space with
   1.113 -whatever you're \emph{really} trying to do.  At the same time,
   1.114 -Mercurial's high performance and peer-to-peer nature let you scale
   1.115 -painlessly to handle large projects.
   1.116 -
   1.117 -No revision control tool can rescue a poorly run project, but a good
   1.118 -choice of tools can make a huge difference to the fluidity with which
   1.119 -you can work on a project.
   1.120 -
   1.121 -\subsection{The many names of revision control}
   1.122 -
   1.123 -Revision control is a diverse field, so much so that it doesn't
   1.124 -actually have a single name or acronym.  Here are a few of the more
   1.125 -common names and acronyms you'll encounter:
   1.126 +La mayoría de estas razones son igualmente validas ---por lo menos en
   1.127 +teoría--- así esté trabajando en un proyecto solo, o con mucha gente.
   1.128 +
   1.129 +Algo fundamental acerca de lo práctico de un sistema de control de
   1.130 +revisiones en estas dos escalas (``un hacker solo'' y ``un equipo
   1.131 +gigantesco'') es cómo se comparan los \emph{beneficios} con los
   1.132 +\emph{costos}.  Una herramienta de control de revisiones que sea
   1.133 +difícil de entender o usar impondrá un costo alto.
   1.134 +
   1.135 +Un proyecto de quinientas personas es muy propenso a colapsar
   1.136 +solamente con su peso inmediatamente sin una herramienta de control de
   1.137 +versiones y un proceso. En este caso, el costo de usar control de
   1.138 +revisiones ni siquiera se tiene en cueant, puesto que \emph{sin} él,
   1.139 +el fracaso está casi garantizado.
   1.140 +
   1.141 +Por otra parte, un ``arreglo rápido'' de una sola persona, excluiría
   1.142 +la necesidad de usar una herramienta de control de revisiones, porque
   1.143 +casi seguramente, el costo de usar una estaría cerca del costo del
   1.144 +proyecto. ¿No es así?
   1.145 +
   1.146 +Mercurial solamente soporta \emph{ambas} escalas de de
   1.147 +desarrollo. Puede aprender lo básico en pocos minutos, y dado su bajo
   1.148 +sobrecosto, puede aplicar el control de revisiones al proyecto más
   1.149 +pequeño con facilidad. Su simplicidad significa que no tendrá que
   1.150 +preocuparse por conceptos obtusos o secuencias de órdenes compitiendo
   1.151 +por espacio mental con lo que sea que \emph{realmente} esté tratando
   1.152 +de hacer.  Al mismo tiempo, Mercurial tiene alto desempeño y su
   1.153 +naturaleza peer-to-peer le permite escalar indoloramente para manejar
   1.154 +grandes proyectos.
   1.155 +
   1.156 +Ninguna herramienta de control de revisiones puede salvar un
   1.157 +proyecto mal administrado, pero la elección de herramientas puede
   1.158 +hacer una gran diferencia en la fluidez con la cual puede trabajar en
   1.159 +el proyecto.
   1.160 +
   1.161 +\subsection{La cantidad de nombres del control de revisiones}
   1.162 +
   1.163 +El control de revisiones es un campo amplio, tan ampli que no hay un
   1.164 +acrónimo o nombre único. A continuación presentamos un listado de
   1.165 +nombres comunes y acrónimos que se podrían encontrar:
   1.166  \begin{itemize}
   1.167 -\item Revision control (RCS)
   1.168 -\item Software configuration management (SCM), or configuration management
   1.169 -\item Source code management
   1.170 -\item Source code control, or source control
   1.171 -\item Version control (VCS)
   1.172 +\item Control de revisiones (RCS)
   1.173 +\item Manejo de Configuraciones de Programas(SCM), o administracón de
   1.174 +  configuraciones
   1.175 +\item Administración de código fuente
   1.176 +\item Control de Código Fuente, o Control de Fuentes
   1.177 +\item Control de Versiones(VCS)
   1.178  \end{itemize}
   1.179 -Some people claim that these terms actually have different meanings,
   1.180 -but in practice they overlap so much that there's no agreed or even
   1.181 -useful way to tease them apart.
   1.182 -
   1.183 -\section{A short history of revision control}
   1.184 -
   1.185 -The best known of the old-time revision control tools is SCCS (Source
   1.186 -Code Control System), which Marc Rochkind wrote at Bell Labs, in the
   1.187 -early 1970s.  SCCS operated on individual files, and required every
   1.188 -person working on a project to have access to a shared workspace on a
   1.189 -single system.  Only one person could modify a file at any time;
   1.190 -arbitration for access to files was via locks.  It was common for
   1.191 -people to lock files, and later forget to unlock them, preventing
   1.192 -anyone else from modifying those files without the help of an
   1.193 -administrator.  
   1.194 -
   1.195 -Walter Tichy developed a free alternative to SCCS in the early 1980s;
   1.196 -he called his program RCS (Revison Control System).  Like SCCS, RCS
   1.197 -required developers to work in a single shared workspace, and to lock
   1.198 -files to prevent multiple people from modifying them simultaneously.
   1.199 -
   1.200 -Later in the 1980s, Dick Grune used RCS as a building block for a set
   1.201 -of shell scripts he initially called cmt, but then renamed to CVS
   1.202 -(Concurrent Versions System).  The big innovation of CVS was that it
   1.203 -let developers work simultaneously and somewhat independently in their
   1.204 -own personal workspaces.  The personal workspaces prevented developers
   1.205 -from stepping on each other's toes all the time, as was common with
   1.206 -SCCS and RCS.  Each developer had a copy of every project file, and
   1.207 -could modify their copies independently.  They had to merge their
   1.208 -edits prior to committing changes to the central repository.
   1.209 -
   1.210 -Brian Berliner took Grune's original scripts and rewrote them in~C,
   1.211 -releasing in 1989 the code that has since developed into the modern
   1.212 -version of CVS.  CVS subsequently acquired the ability to operate over
   1.213 -a network connection, giving it a client/server architecture.  CVS's
   1.214 -architecture is centralised; only the server has a copy of the history
   1.215 -of the project.  Client workspaces just contain copies of recent
   1.216 -versions of the project's files, and a little metadata to tell them
   1.217 -where the server is.  CVS has been enormously successful; it is
   1.218 -probably the world's most widely used revision control system.
   1.219 +Algunas personas aducen que estos términos tienen significados
   1.220 +diversos, pero en la práctica se sobrelapan tanto que no hay un
   1.221 +acuerdo o una forma adecuada de separarlos.
   1.222 +
   1.223 +\section{Historia resumida del control de revisiones}
   1.224 +
   1.225 +La herramienta de control de revisiones más antigua conocida es SCCS 
   1.226 +(Sistema de Control de Código), escrito por Marc Rochkind en Bell
   1.227 +Labs, a comienzos de los setentas(1970s).  SCCS operaba sobre archivos
   1.228 +individuales, y requería que cada persona que trabajara en el proyecto
   1.229 +tuviera acceso a un espacio compartido en un solo sistema.  Solamente
   1.230 +una persona podía modificar un archivo en un momento dado; el
   1.231 +arbitramiento del acceso a los ficheros se hacía con candados. Era
   1.232 +común que la gente pusiera los candados a los ficheros, y que
   1.233 +posteriormente olvidara quitarlos, impidiendo que otro pudiera
   1.234 +modificar los ficheros en cuestión sin la intervención del
   1.235 +administrador.
   1.236 +
   1.237 +Walter Tichy desarrolló una alternativa gratutita a SCCS a comienzos
   1.238 +de los ochentas(1980s), llamó a su programa RCS(Sistema de Control de
   1.239 +Revisiones).  Al igual que SCCS, RCS requería que los desarrolladores
   1.240 +trabajaran en un único espacio compartido y colocaran candados a los
   1.241 +ficheros para evitar que varias personas los estuvieran modificando
   1.242 +simultáneamente.
   1.243 +
   1.244 +Después en los ochenta, Dick Grune usó RCS como un bloque de
   1.245 +construcción para un conjunto de guiones de línea de comando, que
   1.246 +inicialmente llamó cmt, pero que renombró a CVS(Sistema Concurrente de
   1.247 +Versiones).  La gran innovación de CVS era que permitía a los
   1.248 +desarrolladores trabajar simultáneamente de una forma más o menos
   1.249 +independiente en sus propios espacios de trabajo. Los espacios de
   1.250 +trabajo personales impedian que los desarrolladores se pisaran las
   1.251 +mangueras todo el tiempo, situación común con SCCS y RCS.  Cada
   1.252 +desarrollador tenía una copia de todo el fichero del proyecto y podía
   1.253 +modificar su copia independientemente, Tenían que fusionar sus
   1.254 +ediciones antes de consignar los cambios al repositorio central.
   1.255 +
   1.256 +Brian Berliner tomó los scripts originales de Grune y los reescribió
   1.257 +en~C, haciéndolos públicos en 1989, código sobre el cual se ha
   1.258 +desarrollado la versión moderna de CVS.  CVS posteriormente adquirió
   1.259 +la habilidad de operar sobre una conexión de red, dotándolo de una
   1.260 +arquitectura, cliente/servidor. La arquitectura de CVS es
   1.261 +centralizada; La historia del proyecto está únicamente en el
   1.262 +repositorio central.  Los espacios de trabajo de los clientes
   1.263 +contienen únicamente copias recientes de las versiones de los
   1.264 +ficheros, y pocos metadatos para indicar dónde está el servidor. CVS
   1.265 +ha tenido un éxito enorme; Es probablemente el sistema de control de
   1.266 +revisiones más extendido del planeta.
   1.267  
   1.268  In the early 1990s, Sun Microsystems developed an early distributed
   1.269  revision control system, called TeamWare.  A TeamWare workspace