1.1 --- a/es/intro.tex	Sat Nov 08 19:31:13 2008 -0500
     1.2 +++ b/es/intro.tex	Sat Nov 08 21:47:35 2008 -0500
     1.3 @@ -141,167 +141,184 @@
     1.4  ha tenido un éxito enorme; Es probablemente el sistema de control de
     1.5  revisiones más extendido del planeta.
     1.6  
     1.7 -In the early 1990s, Sun Microsystems developed an early distributed
     1.8 -revision control system, called TeamWare.  A TeamWare workspace
     1.9 -contains a complete copy of the project's history.  TeamWare has no
    1.10 -notion of a central repository.  (CVS relied upon RCS for its history
    1.11 -storage; TeamWare used SCCS.)
    1.12 -
    1.13 -As the 1990s progressed, awareness grew of a number of problems with
    1.14 -CVS.  It records simultaneous changes to multiple files individually,
    1.15 -instead of grouping them together as a single logically atomic
    1.16 -operation.  It does not manage its file hierarchy well; it is easy to
    1.17 -make a mess of a repository by renaming files and directories.  Worse,
    1.18 -its source code is difficult to read and maintain, which made the
    1.19 -``pain level'' of fixing these architectural problems prohibitive.
    1.20 -
    1.21 -In 2001, Jim Blandy and Karl Fogel, two developers who had worked on
    1.22 -CVS, started a project to replace it with a tool that would have a
    1.23 -better architecture and cleaner code.  The result, Subversion, does
    1.24 -not stray from CVS's centralised client/server model, but it adds
    1.25 -multi-file atomic commits, better namespace management, and a number
    1.26 -of other features that make it a generally better tool than CVS.
    1.27 -Since its initial release, it has rapidly grown in popularity.
    1.28 -
    1.29 -More or less simultaneously, Graydon Hoare began working on an
    1.30 -ambitious distributed revision control system that he named Monotone.
    1.31 -While Monotone addresses many of CVS's design flaws and has a
    1.32 -peer-to-peer architecture, it goes beyond earlier (and subsequent)
    1.33 -revision control tools in a number of innovative ways.  It uses
    1.34 -cryptographic hashes as identifiers, and has an integral notion of
    1.35 -``trust'' for code from different sources.
    1.36 -
    1.37 -Mercurial began life in 2005.  While a few aspects of its design are
    1.38 -influenced by Monotone, Mercurial focuses on ease of use, high
    1.39 -performance, and scalability to very large projects.
    1.40 -
    1.41 -\section{Trends in revision control}
    1.42 -
    1.43 -There has been an unmistakable trend in the development and use of
    1.44 -revision control tools over the past four decades, as people have
    1.45 -become familiar with the capabilities of their tools and constrained
    1.46 -by their limitations.
    1.47 -
    1.48 -The first generation began by managing single files on individual
    1.49 -computers.  Although these tools represented a huge advance over
    1.50 -ad-hoc manual revision control, their locking model and reliance on a
    1.51 -single computer limited them to small, tightly-knit teams.
    1.52 -
    1.53 -The second generation loosened these constraints by moving to
    1.54 -network-centered architectures, and managing entire projects at a
    1.55 -time.  As projects grew larger, they ran into new problems.  With
    1.56 -clients needing to talk to servers very frequently, server scaling
    1.57 -became an issue for large projects.  An unreliable network connection
    1.58 -could prevent remote users from being able to talk to the server at
    1.59 -all.  As open source projects started making read-only access
    1.60 -available anonymously to anyone, people without commit privileges
    1.61 -found that they could not use the tools to interact with a project in
    1.62 -a natural way, as they could not record their changes.
    1.63 -
    1.64 -The current generation of revision control tools is peer-to-peer in
    1.65 -nature.  All of these systems have dropped the dependency on a single
    1.66 -central server, and allow people to distribute their revision control
    1.67 -data to where it's actually needed.  Collaboration over the Internet
    1.68 -has moved from constrained by technology to a matter of choice and
    1.69 -consensus.  Modern tools can operate offline indefinitely and
    1.70 -autonomously, with a network connection only needed when syncing
    1.71 -changes with another repository.
    1.72 -
    1.73 -\section{A few of the advantages of distributed revision control}
    1.74 -
    1.75 -Even though distributed revision control tools have for several years
    1.76 -been as robust and usable as their previous-generation counterparts,
    1.77 -people using older tools have not yet necessarily woken up to their
    1.78 -advantages.  There are a number of ways in which distributed tools
    1.79 -shine relative to centralised ones.
    1.80 -
    1.81 -For an individual developer, distributed tools are almost always much
    1.82 -faster than centralised tools.  This is for a simple reason: a
    1.83 -centralised tool needs to talk over the network for many common
    1.84 -operations, because most metadata is stored in a single copy on the
    1.85 -central server.  A distributed tool stores all of its metadata
    1.86 -locally.  All else being equal, talking over the network adds overhead
    1.87 -to a centralised tool.  Don't underestimate the value of a snappy,
    1.88 -responsive tool: you're going to spend a lot of time interacting with
    1.89 -your revision control software.
    1.90 -
    1.91 -Distributed tools are indifferent to the vagaries of your server
    1.92 -infrastructure, again because they replicate metadata to so many
    1.93 -locations.  If you use a centralised system and your server catches
    1.94 -fire, you'd better hope that your backup media are reliable, and that
    1.95 -your last backup was recent and actually worked.  With a distributed
    1.96 -tool, you have many backups available on every contributor's computer.
    1.97 -
    1.98 -The reliability of your network will affect distributed tools far less
    1.99 -than it will centralised tools.  You can't even use a centralised tool
   1.100 -without a network connection, except for a few highly constrained
   1.101 -commands.  With a distributed tool, if your network connection goes
   1.102 -down while you're working, you may not even notice.  The only thing
   1.103 -you won't be able to do is talk to repositories on other computers,
   1.104 -something that is relatively rare compared with local operations.  If
   1.105 -you have a far-flung team of collaborators, this may be significant.
   1.106 -
   1.107 -\subsection{Advantages for open source projects}
   1.108 -
   1.109 -If you take a shine to an open source project and decide that you
   1.110 -would like to start hacking on it, and that project uses a distributed
   1.111 -revision control tool, you are at once a peer with the people who
   1.112 -consider themselves the ``core'' of that project.  If they publish
   1.113 -their repositories, you can immediately copy their project history,
   1.114 -start making changes, and record your work, using the same tools in
   1.115 -the same ways as insiders.  By contrast, with a centralised tool, you
   1.116 -must use the software in a ``read only'' mode unless someone grants
   1.117 -you permission to commit changes to their central server.  Until then,
   1.118 -you won't be able to record changes, and your local modifications will
   1.119 -be at risk of corruption any time you try to update your client's view
   1.120 -of the repository.
   1.121 -
   1.122 -\subsubsection{The forking non-problem}
   1.123 -
   1.124 -It has been suggested that distributed revision control tools pose
   1.125 -some sort of risk to open source projects because they make it easy to
   1.126 -``fork'' the development of a project.  A fork happens when there are
   1.127 -differences in opinion or attitude between groups of developers that
   1.128 -cause them to decide that they can't work together any longer.  Each
   1.129 -side takes a more or less complete copy of the project's source code,
   1.130 -and goes off in its own direction.
   1.131 -
   1.132 -Sometimes the camps in a fork decide to reconcile their differences.
   1.133 -With a centralised revision control system, the \emph{technical}
   1.134 -process of reconciliation is painful, and has to be performed largely
   1.135 -by hand.  You have to decide whose revision history is going to
   1.136 -``win'', and graft the other team's changes into the tree somehow.
   1.137 -This usually loses some or all of one side's revision history.
   1.138 -
   1.139 -What distributed tools do with respect to forking is they make forking
   1.140 -the \emph{only} way to develop a project.  Every single change that
   1.141 -you make is potentially a fork point.  The great strength of this
   1.142 -approach is that a distributed revision control tool has to be really
   1.143 -good at \emph{merging} forks, because forks are absolutely
   1.144 -fundamental: they happen all the time.  
   1.145 -
   1.146 -If every piece of work that everybody does, all the time, is framed in
   1.147 -terms of forking and merging, then what the open source world refers
   1.148 -to as a ``fork'' becomes \emph{purely} a social issue.  If anything,
   1.149 -distributed tools \emph{lower} the likelihood of a fork:
   1.150 +A comienzos de los noventa(1990s), Sun MicroSystems desarrollo un
   1.151 +temprano sistema distribuido de revisión de controles llamado TeamWare
   1.152 +Un espacio de trabajo TeamWare contiene una copia completa de la
   1.153 +historia del proyecto. TeamWare no tiene la noción de repositorio
   1.154 +central. (CVS se basaba en RCS para el almacenamiento de su historia;
   1.155 +TeamWare usaba SCCS.)
   1.156 +
   1.157 +A medida que avanzaba la decada de los noventa, se empezño a
   1.158 +evidenciar los problemas de CVS.  Alacena cambios simultáneos a muchos
   1.159 +archivos de forma individual, en lugar de agruparlos como una
   1.160 +operación única y atómica lógicamente.  No maneja bien su jerarquía de
   1.161 +ficheros bien; es fácil desordenar un repositorio renombrando ficheros
   1.162 +y directorios. Peor aún, su código fuente es difícil de leer y
   1.163 +mantener, lo que hace que su ``umbral de dolor'' para arreglar sus
   1.164 +problemas arquitecturales algo prohibitivo.
   1.165 +
   1.166 +En 2001, Jim Blandy y Karl Fogel, dos desarrolladores que habían
   1.167 +trabajado en CVS, comenzaron un proyecto para reemplazarlo con una
   1.168 +herramienta con mejor arquitectura y código más limpio.  El resultado,
   1.169 +Subversion, no se separó del modelo centralizado cliente/servidor de
   1.170 +CVS, pero añadió consignaciones atómicas de varios ficheros, mejor
   1.171 +manejo de nombres de espacios, y otras características que lo hacen
   1.172 +mejor que CVS. Desde su versión inicial, ha ido creciendo en
   1.173 +popularidad.
   1.174 +
   1.175 +Más o menos en forma simultánea Graydon Hoare comenzó a trabajar en un
   1.176 +sistema distribuido de control de versiones ambicioso que llamó
   1.177 +Monotone. Mientras que Monotone se enfocaba a evitar algunas fallas de
   1.178 +diseño de CVS con una arquitectura peer-to-peer, fue mucho más
   1.179 +allá(junto con otros proyectos subsecuentes) que unas herramientas de
   1.180 +control de revisiones en varios aspectos innovadores. Usa hashes
   1.181 +criptográficos como identificadores, y tiene una noción integral de 
   1.182 +``confianza'' para código de diversas fuentes.
   1.183 +
   1.184 +Mercurial nació en el 2005.  Algunos de sus aspectos de de diseño
   1.185 +fueron influenciados por Monotone, pero Mercurial se enfoca en la
   1.186 +facilidad de uso, gran rendimiento y escalabilidad para proyectos muy
   1.187 +grandes.
   1.188 +
   1.189 +\section{Tendencias en el control de revisiones}
   1.190 +
   1.191 +Ha habido varias tendencias en el desarrollo y uso de las herramientas
   1.192 +de control de revisiones en las pasadas cuatro décadas, mientras la
   1.193 +gente se ha vuelto familiar con las capacidades de sus herramientas
   1.194 +así mismo con sus limitaciones.
   1.195 +
   1.196 +La primera generación comenzó administrando archivos individuales en
   1.197 +computadores por persona. A pesar de que tales herramientas
   1.198 +representaron un avance importante frente al control de revisiones
   1.199 +manual, su modelo de candados y la limitación a un sólo computador,
   1.200 +determinó equipos de trabajo pequeños y acoplados.
   1.201 +
   1.202 +La segunda generación dejó atrás esas limitaciones moviéndose a
   1.203 +arquitecturas centradas en  redes, y administrando proyectos completos
   1.204 +uno a la vez. A medida que los proyectos crecían, nacieron nuevos
   1.205 +problemas. Con la necesidad de comunicación frecuente con los
   1.206 +servidores, escalar estas máquinas se convirtió en un problema en
   1.207 +proyectos realmente grandes. Las redes con poca estabilidad impidieron
   1.208 +que usuarios remotos se conectaran al servidor. A medida que los
   1.209 +proyecos de código abierto comenzaron a ofrecer acceso de sólo lectura
   1.210 +de forma anónima a cualquiera, la gente sin permiso para consignar,
   1.211 +vio que no podían usar tales herramientas para interactuar en un
   1.212 +proyecto de forma natural, puesto que no podían guardar sus cambios.
   1.213 +
   1.214 +La generación actual de herramientas de control de revisiones es de
   1.215 +forma natural peer-to-peer.  Todos estos sistemas han eliminado la
   1.216 +dependencia de un único servidor central, y han permitido que la
   1.217 +gente distribuya sus datos de control de revisiones donde realmente se
   1.218 +necesita. La colaboración a través de Internet ha cambiado las
   1.219 +limitantes tecnológicas a la cuestión de elección y consenso. Las
   1.220 +herramientas modernas pueden operar sin conexión indefinidamenta y
   1.221 +autónomamente, necesitando una conexión de red solamente para
   1.222 +sincronizar los cambios con otro repositorio.
   1.223 +
   1.224 +\section{Algunas ventajas del control distribuido de revisiones}
   1.225 +
   1.226 +A pesar de que las herramientas para el control distribuido de
   1.227 +revisiones lleva varios años siendo tan robusto y usable como la
   1.228 +generación previa de su contraparte, personas que usan herramientas
   1.229 +más antiguas no se han percatado de sus ventajas.  Hay gran cantidad
   1.230 +de situaciones en las cuales las herramientas distribuidas brillan
   1.231 +frente a las centralizadas.
   1.232 +
   1.233 +Para un desarrollador individual, las herramientas distribuidas casi
   1.234 +siempre son más rápidas que las centralizadas. Por una razón sencilla:
   1.235 +Una herramienta centralizada necesita comunicarse por red para las
   1.236 +operaciones más usuales, debido a que los metadatos se almacenan en
   1.237 +una sola copia en el servidor central. Una herramienta distribuida
   1.238 +almacena todos sus metadatos localmente.  Con todo lo demás de la
   1.239 +misma forma, comunicarse por red tiene un sobrecosto en una
   1.240 +herramienta centralizada. No subestime el valor de una herramienta de
   1.241 +respuesta rápida: Usted empleará mucho tiempo interactuando con su
   1.242 +programa de control de revisiones.
   1.243 +
   1.244 +Las herramientas distribuidas son indiferentes a los caprichos de su
   1.245 +infraestructura de servidores, de nuevo, debido a la replicación de
   1.246 +metadatos en tantos lugares. Si usa un sistema centralizado y su
   1.247 +servidor explota, ojalá los medios físicos de su copia de seguridad
   1.248 +sean confiables, y que su última copia sea reciente y además
   1.249 +funcione. Con una herramienta distribuida tiene tantas copias de
   1.250 +seguridad disponibles como computadores de contribuidores.
   1.251 +
   1.252 +La confiabilidad de su red afectará las herramientas distribuidas de
   1.253 +una forma mucho menor que las herramientas centralizadas No puede
   1.254 +siquiera usar una herramienta centralizada sin conexión de red,
   1.255 +excepto con algunas órdenes muy limitadas. Con herramientas
   1.256 +distribuidas, si sus conexión cae mientras usted está trabajando,
   1.257 +podría nisiquiera darse cuenta. Lo único que que no podrá hacer es
   1.258 +comunicarse  con repositorios en otros computadores, algo que es
   1.259 +relativamente raro comparado con las operaciones locales. Si tiene
   1.260 +colaboradores remotos en su equipo, puede ser significante.
   1.261 +
   1.262 +\subsection{Ventajas para proyectos de código abierto}
   1.263 +
   1.264 +Si descubre un proyecto de código abierto y decide que desea comenzar
   1.265 +a trabajar en él, y ese proyecto usa una herramienta de control
   1.266 +distribuido de revisiones, usted es un par con la gente que se
   1.267 +considera el ``alma'' del proyecto.  Si ellos publican los
   1.268 +repositorios, se puede copiar inmediatamente la historia del proyecto,
   1.269 +hacer cambios y guardar su trabajo, usando las mismas herramientas de
   1.270 +la misma forma que ellos. En contraste, con una herramienta
   1.271 +centralizada, debe usar el programa en un modo ``sólo lectura'' a
   1.272 +menos que alguien le otorgue permisos para consignar cambios en el
   1.273 +repositorio central. Hasta entonces, no podrá almacenar sus cambios y
   1.274 +sus modificaciones locales correrán el riesgo de dañarse cuando trate
   1.275 +de actualizar su vista del repositorio.
   1.276 +
   1.277 +\subsubsection{Las bifurcaciones(forks) no son un problema}
   1.278 +
   1.279 +Se ha mencionado que las herramientas de control distribuido de
   1.280 +versiones albergan un riesgo a los proyectos de código abierto, puesto
   1.281 +que se vuelve muy sencillo hacer una ``bifurcanción''\NdT{fork} del
   1.282 +desarrollo del proyecto.  Una bifurcación pasa cuando hay diferencias
   1.283 +de opinión o actitud entre grupos de desarrolladores que desenvoca en
   1.284 +la decisión de la imposibilidad de continuar trabajando juntos. Cada
   1.285 +parte toma una copia más o menos completa del código fuente del
   1.286 +proyecto y toma su propio rumbo.
   1.287 +
   1.288 +En algunas ocasiones los líderes de las bifurcaciones reconcilian sus
   1.289 +diferencias. Con un sistema centralizado de control de revisiones, el
   1.290 +proceso \emph{técnico} de reconciliarse es doloroso, y se hace de
   1.291 +forma muy manual.  Tiene que decidir qué historia de revisiones va a
   1.292 +``win'', e injertar los cambios del otro equipo en el árbol de alguna
   1.293 +manera. Con esto usualmente se pierde algo o todo del historial de la
   1.294 +revisión de alguna de las partes.
   1.295 +
   1.296 +Lo que las herramientas distribuidas hacen con respecto a las
   1.297 +bifurcaciones, es que las bifurcaciones son la \emph{única} forma de
   1.298 +desarrollar un proyecto. Cada cambio que usted hace es potencialmente
   1.299 +un punto de bifurcación. La gran fortaleza de esta aproximación es que
   1.300 +las herramientas distribuidas de control de revisiones tiene que ser
   1.301 +bueno al \emph{fusionar} las bifurcaciones, porque las bifurcaciones
   1.302 +son absolutamente fundamentales: pasan todo el tiempo.
   1.303 +
   1.304 +Si todas las porciones de trabajo que todos hacen todo el tiempo, se
   1.305 +enmarca en términos de bifurcaciones y fusiones, entonces a aquello a
   1.306 +lo que se refiere en el mundo del código abierto a una ``bifurcación''
   1.307 +se convierte \emph{puramente} en una cuestión social. Lo que hacen las
   1.308 +herramientas distribuidas es \emph{disminuir} la posibilidad de una
   1.309 +bifurcación porque:
   1.310  \begin{itemize}
   1.311 -\item They eliminate the social distinction that centralised tools
   1.312 -  impose: that between insiders (people with commit access) and
   1.313 -  outsiders (people without).
   1.314 -\item They make it easier to reconcile after a social fork, because
   1.315 -  all that's involved from the perspective of the revision control
   1.316 -  software is just another merge.
   1.317 +\item Eliminan la distinción social que las herramientas centralizadas
   1.318 +  imponen: esto entre los miembros (personas con permiso de consignar)
   1.319 +  y forasteros(los que no tienen el permiso).
   1.320 +\item Facilitan la reconciliación después de una bifurcación social,
   1.321 +  porque todo lo que concierne al programa de control de revisiones es
   1.322 +  una fusión.
   1.323  \end{itemize}
   1.324  
   1.325 -Some people resist distributed tools because they want to retain tight
   1.326 -control over their projects, and they believe that centralised tools
   1.327 -give them this control.  However, if you're of this belief, and you
   1.328 -publish your CVS or Subversion repositories publically, there are
   1.329 -plenty of tools available that can pull out your entire project's
   1.330 -history (albeit slowly) and recreate it somewhere that you don't
   1.331 -control.  So while your control in this case is illusory, you are
   1.332 -forgoing the ability to fluidly collaborate with whatever people feel
   1.333 -compelled to mirror and fork your history.
   1.334 +Algunas personas se resisten a las herramientas distribuidas porque
   1.335 +desean mantener control completo sobre sus proyectos, y creen que las
   1.336 +herramientas centralizadas les dan tal control. En todo caso, si este
   1.337 +es su parecer, y publica sus repositorios de CVS o Subversion, hay
   1.338 +muchas herramientas disponibles que pueden obtener la historia
   1.339 +completa(A pesar de lo lento) y recrearla en otro sitio que usted no
   1.340 +controla. Siendo así un control ilusorio, está impidiendo la fluidez
   1.341 +de colaboración frente a quien se sienta impulsado a obtener una copia
   1.342 +y hacer una bifurcación con su historia.
   1.343  
   1.344  \subsection{Advantages for commercial projects}
   1.345