1.1 --- a/es/Leame.1st	Sat Nov 08 19:31:13 2008 -0500
     1.2 +++ b/es/Leame.1st	Sat Nov 08 21:47:35 2008 -0500
     1.3 @@ -102,7 +102,7 @@
     1.4  || undo.tex        || Igor Támara   ||    100%    || 26/10/2008 ||  07/11/2008 ||
     1.5  || tour-merge.tex  || Javier Rojas  ||    100%    || 28/10/2008 ||  03/11/2008 ||
     1.6  || concepts.tex    || Javier Rojas  ||      7%    || 03/11/2008 ||             ||
     1.7 -|| intro.tex	   || Igor Támara   ||	    0%	  || 08/11/2008	||	       ||
     1.8 +|| intro.tex	   || Igor Támara   ||	   51%	  || 08/11/2008	||	       ||
     1.9  
    1.10  == Archivos en proceso de revisión ==
    1.11  ||'''archivo'''   || '''revisor''' ||'''Estado'''||'''Inicio'''||  '''Fin'''  ||
    1.12 @@ -143,8 +143,10 @@
    1.13   Changeset: Conjunto de Cambios
    1.14   Command: Orden
    1.15   Commit: Consignar
    1.16 + Core: alma
    1.17   Directory: Directorio
    1.18   File: Archivo
    1.19 + Fork: Bifurcación
    1.20   Head: Principal. En el contexto de revisiones HEAD se sugiere usar "frente"
    1.21   Hook: Gancho
    1.22   Merge: Fusión

     2.1 --- a/es/intro.tex	Sat Nov 08 19:31:13 2008 -0500
     2.2 +++ b/es/intro.tex	Sat Nov 08 21:47:35 2008 -0500
     2.3 @@ -141,167 +141,184 @@
     2.4  ha tenido un éxito enorme; Es probablemente el sistema de control de
     2.5  revisiones más extendido del planeta.
     2.6  
     2.7 -In the early 1990s, Sun Microsystems developed an early distributed
     2.8 -revision control system, called TeamWare.  A TeamWare workspace
     2.9 -contains a complete copy of the project's history.  TeamWare has no
    2.10 -notion of a central repository.  (CVS relied upon RCS for its history
    2.11 -storage; TeamWare used SCCS.)
    2.12 -
    2.13 -As the 1990s progressed, awareness grew of a number of problems with
    2.14 -CVS.  It records simultaneous changes to multiple files individually,
    2.15 -instead of grouping them together as a single logically atomic
    2.16 -operation.  It does not manage its file hierarchy well; it is easy to
    2.17 -make a mess of a repository by renaming files and directories.  Worse,
    2.18 -its source code is difficult to read and maintain, which made the
    2.19 -``pain level'' of fixing these architectural problems prohibitive.
    2.20 -
    2.21 -In 2001, Jim Blandy and Karl Fogel, two developers who had worked on
    2.22 -CVS, started a project to replace it with a tool that would have a
    2.23 -better architecture and cleaner code.  The result, Subversion, does
    2.24 -not stray from CVS's centralised client/server model, but it adds
    2.25 -multi-file atomic commits, better namespace management, and a number
    2.26 -of other features that make it a generally better tool than CVS.
    2.27 -Since its initial release, it has rapidly grown in popularity.
    2.28 -
    2.29 -More or less simultaneously, Graydon Hoare began working on an
    2.30 -ambitious distributed revision control system that he named Monotone.
    2.31 -While Monotone addresses many of CVS's design flaws and has a
    2.32 -peer-to-peer architecture, it goes beyond earlier (and subsequent)
    2.33 -revision control tools in a number of innovative ways.  It uses
    2.34 -cryptographic hashes as identifiers, and has an integral notion of
    2.35 -``trust'' for code from different sources.
    2.36 -
    2.37 -Mercurial began life in 2005.  While a few aspects of its design are
    2.38 -influenced by Monotone, Mercurial focuses on ease of use, high
    2.39 -performance, and scalability to very large projects.
    2.40 -
    2.41 -\section{Trends in revision control}
    2.42 -
    2.43 -There has been an unmistakable trend in the development and use of
    2.44 -revision control tools over the past four decades, as people have
    2.45 -become familiar with the capabilities of their tools and constrained
    2.46 -by their limitations.
    2.47 -
    2.48 -The first generation began by managing single files on individual
    2.49 -computers.  Although these tools represented a huge advance over
    2.50 -ad-hoc manual revision control, their locking model and reliance on a
    2.51 -single computer limited them to small, tightly-knit teams.
    2.52 -
    2.53 -The second generation loosened these constraints by moving to
    2.54 -network-centered architectures, and managing entire projects at a
    2.55 -time.  As projects grew larger, they ran into new problems.  With
    2.56 -clients needing to talk to servers very frequently, server scaling
    2.57 -became an issue for large projects.  An unreliable network connection
    2.58 -could prevent remote users from being able to talk to the server at
    2.59 -all.  As open source projects started making read-only access
    2.60 -available anonymously to anyone, people without commit privileges
    2.61 -found that they could not use the tools to interact with a project in
    2.62 -a natural way, as they could not record their changes.
    2.63 -
    2.64 -The current generation of revision control tools is peer-to-peer in
    2.65 -nature.  All of these systems have dropped the dependency on a single
    2.66 -central server, and allow people to distribute their revision control
    2.67 -data to where it's actually needed.  Collaboration over the Internet
    2.68 -has moved from constrained by technology to a matter of choice and
    2.69 -consensus.  Modern tools can operate offline indefinitely and
    2.70 -autonomously, with a network connection only needed when syncing
    2.71 -changes with another repository.
    2.72 -
    2.73 -\section{A few of the advantages of distributed revision control}
    2.74 -
    2.75 -Even though distributed revision control tools have for several years
    2.76 -been as robust and usable as their previous-generation counterparts,
    2.77 -people using older tools have not yet necessarily woken up to their
    2.78 -advantages.  There are a number of ways in which distributed tools
    2.79 -shine relative to centralised ones.
    2.80 -
    2.81 -For an individual developer, distributed tools are almost always much
    2.82 -faster than centralised tools.  This is for a simple reason: a
    2.83 -centralised tool needs to talk over the network for many common
    2.84 -operations, because most metadata is stored in a single copy on the
    2.85 -central server.  A distributed tool stores all of its metadata
    2.86 -locally.  All else being equal, talking over the network adds overhead
    2.87 -to a centralised tool.  Don't underestimate the value of a snappy,
    2.88 -responsive tool: you're going to spend a lot of time interacting with
    2.89 -your revision control software.
    2.90 -
    2.91 -Distributed tools are indifferent to the vagaries of your server
    2.92 -infrastructure, again because they replicate metadata to so many
    2.93 -locations.  If you use a centralised system and your server catches
    2.94 -fire, you'd better hope that your backup media are reliable, and that
    2.95 -your last backup was recent and actually worked.  With a distributed
    2.96 -tool, you have many backups available on every contributor's computer.
    2.97 -
    2.98 -The reliability of your network will affect distributed tools far less
    2.99 -than it will centralised tools.  You can't even use a centralised tool
   2.100 -without a network connection, except for a few highly constrained
   2.101 -commands.  With a distributed tool, if your network connection goes
   2.102 -down while you're working, you may not even notice.  The only thing
   2.103 -you won't be able to do is talk to repositories on other computers,
   2.104 -something that is relatively rare compared with local operations.  If
   2.105 -you have a far-flung team of collaborators, this may be significant.
   2.106 -
   2.107 -\subsection{Advantages for open source projects}
   2.108 -
   2.109 -If you take a shine to an open source project and decide that you
   2.110 -would like to start hacking on it, and that project uses a distributed
   2.111 -revision control tool, you are at once a peer with the people who
   2.112 -consider themselves the ``core'' of that project.  If they publish
   2.113 -their repositories, you can immediately copy their project history,
   2.114 -start making changes, and record your work, using the same tools in
   2.115 -the same ways as insiders.  By contrast, with a centralised tool, you
   2.116 -must use the software in a ``read only'' mode unless someone grants
   2.117 -you permission to commit changes to their central server.  Until then,
   2.118 -you won't be able to record changes, and your local modifications will
   2.119 -be at risk of corruption any time you try to update your client's view
   2.120 -of the repository.
   2.121 -
   2.122 -\subsubsection{The forking non-problem}
   2.123 -
   2.124 -It has been suggested that distributed revision control tools pose
   2.125 -some sort of risk to open source projects because they make it easy to
   2.126 -``fork'' the development of a project.  A fork happens when there are
   2.127 -differences in opinion or attitude between groups of developers that
   2.128 -cause them to decide that they can't work together any longer.  Each
   2.129 -side takes a more or less complete copy of the project's source code,
   2.130 -and goes off in its own direction.
   2.131 -
   2.132 -Sometimes the camps in a fork decide to reconcile their differences.
   2.133 -With a centralised revision control system, the \emph{technical}
   2.134 -process of reconciliation is painful, and has to be performed largely
   2.135 -by hand.  You have to decide whose revision history is going to
   2.136 -``win'', and graft the other team's changes into the tree somehow.
   2.137 -This usually loses some or all of one side's revision history.
   2.138 -
   2.139 -What distributed tools do with respect to forking is they make forking
   2.140 -the \emph{only} way to develop a project.  Every single change that
   2.141 -you make is potentially a fork point.  The great strength of this
   2.142 -approach is that a distributed revision control tool has to be really
   2.143 -good at \emph{merging} forks, because forks are absolutely
   2.144 -fundamental: they happen all the time.  
   2.145 -
   2.146 -If every piece of work that everybody does, all the time, is framed in
   2.147 -terms of forking and merging, then what the open source world refers
   2.148 -to as a ``fork'' becomes \emph{purely} a social issue.  If anything,
   2.149 -distributed tools \emph{lower} the likelihood of a fork:
   2.150 +A comienzos de los noventa(1990s), Sun MicroSystems desarrollo un
   2.151 +temprano sistema distribuido de revisión de controles llamado TeamWare
   2.152 +Un espacio de trabajo TeamWare contiene una copia completa de la
   2.153 +historia del proyecto. TeamWare no tiene la noción de repositorio
   2.154 +central. (CVS se basaba en RCS para el almacenamiento de su historia;
   2.155 +TeamWare usaba SCCS.)
   2.156 +
   2.157 +A medida que avanzaba la decada de los noventa, se empezño a
   2.158 +evidenciar los problemas de CVS.  Alacena cambios simultáneos a muchos
   2.159 +archivos de forma individual, en lugar de agruparlos como una
   2.160 +operación única y atómica lógicamente.  No maneja bien su jerarquía de
   2.161 +ficheros bien; es fácil desordenar un repositorio renombrando ficheros
   2.162 +y directorios. Peor aún, su código fuente es difícil de leer y
   2.163 +mantener, lo que hace que su ``umbral de dolor'' para arreglar sus
   2.164 +problemas arquitecturales algo prohibitivo.
   2.165 +
   2.166 +En 2001, Jim Blandy y Karl Fogel, dos desarrolladores que habían
   2.167 +trabajado en CVS, comenzaron un proyecto para reemplazarlo con una
   2.168 +herramienta con mejor arquitectura y código más limpio.  El resultado,
   2.169 +Subversion, no se separó del modelo centralizado cliente/servidor de
   2.170 +CVS, pero añadió consignaciones atómicas de varios ficheros, mejor
   2.171 +manejo de nombres de espacios, y otras características que lo hacen
   2.172 +mejor que CVS. Desde su versión inicial, ha ido creciendo en
   2.173 +popularidad.
   2.174 +
   2.175 +Más o menos en forma simultánea Graydon Hoare comenzó a trabajar en un
   2.176 +sistema distribuido de control de versiones ambicioso que llamó
   2.177 +Monotone. Mientras que Monotone se enfocaba a evitar algunas fallas de
   2.178 +diseño de CVS con una arquitectura peer-to-peer, fue mucho más
   2.179 +allá(junto con otros proyectos subsecuentes) que unas herramientas de
   2.180 +control de revisiones en varios aspectos innovadores. Usa hashes
   2.181 +criptográficos como identificadores, y tiene una noción integral de 
   2.182 +``confianza'' para código de diversas fuentes.
   2.183 +
   2.184 +Mercurial nació en el 2005.  Algunos de sus aspectos de de diseño
   2.185 +fueron influenciados por Monotone, pero Mercurial se enfoca en la
   2.186 +facilidad de uso, gran rendimiento y escalabilidad para proyectos muy
   2.187 +grandes.
   2.188 +
   2.189 +\section{Tendencias en el control de revisiones}
   2.190 +
   2.191 +Ha habido varias tendencias en el desarrollo y uso de las herramientas
   2.192 +de control de revisiones en las pasadas cuatro décadas, mientras la
   2.193 +gente se ha vuelto familiar con las capacidades de sus herramientas
   2.194 +así mismo con sus limitaciones.
   2.195 +
   2.196 +La primera generación comenzó administrando archivos individuales en
   2.197 +computadores por persona. A pesar de que tales herramientas
   2.198 +representaron un avance importante frente al control de revisiones
   2.199 +manual, su modelo de candados y la limitación a un sólo computador,
   2.200 +determinó equipos de trabajo pequeños y acoplados.
   2.201 +
   2.202 +La segunda generación dejó atrás esas limitaciones moviéndose a
   2.203 +arquitecturas centradas en  redes, y administrando proyectos completos
   2.204 +uno a la vez. A medida que los proyectos crecían, nacieron nuevos
   2.205 +problemas. Con la necesidad de comunicación frecuente con los
   2.206 +servidores, escalar estas máquinas se convirtió en un problema en
   2.207 +proyectos realmente grandes. Las redes con poca estabilidad impidieron
   2.208 +que usuarios remotos se conectaran al servidor. A medida que los
   2.209 +proyecos de código abierto comenzaron a ofrecer acceso de sólo lectura
   2.210 +de forma anónima a cualquiera, la gente sin permiso para consignar,
   2.211 +vio que no podían usar tales herramientas para interactuar en un
   2.212 +proyecto de forma natural, puesto que no podían guardar sus cambios.
   2.213 +
   2.214 +La generación actual de herramientas de control de revisiones es de
   2.215 +forma natural peer-to-peer.  Todos estos sistemas han eliminado la
   2.216 +dependencia de un único servidor central, y han permitido que la
   2.217 +gente distribuya sus datos de control de revisiones donde realmente se
   2.218 +necesita. La colaboración a través de Internet ha cambiado las
   2.219 +limitantes tecnológicas a la cuestión de elección y consenso. Las
   2.220 +herramientas modernas pueden operar sin conexión indefinidamenta y
   2.221 +autónomamente, necesitando una conexión de red solamente para
   2.222 +sincronizar los cambios con otro repositorio.
   2.223 +
   2.224 +\section{Algunas ventajas del control distribuido de revisiones}
   2.225 +
   2.226 +A pesar de que las herramientas para el control distribuido de
   2.227 +revisiones lleva varios años siendo tan robusto y usable como la
   2.228 +generación previa de su contraparte, personas que usan herramientas
   2.229 +más antiguas no se han percatado de sus ventajas.  Hay gran cantidad
   2.230 +de situaciones en las cuales las herramientas distribuidas brillan
   2.231 +frente a las centralizadas.
   2.232 +
   2.233 +Para un desarrollador individual, las herramientas distribuidas casi
   2.234 +siempre son más rápidas que las centralizadas. Por una razón sencilla:
   2.235 +Una herramienta centralizada necesita comunicarse por red para las
   2.236 +operaciones más usuales, debido a que los metadatos se almacenan en
   2.237 +una sola copia en el servidor central. Una herramienta distribuida
   2.238 +almacena todos sus metadatos localmente.  Con todo lo demás de la
   2.239 +misma forma, comunicarse por red tiene un sobrecosto en una
   2.240 +herramienta centralizada. No subestime el valor de una herramienta de
   2.241 +respuesta rápida: Usted empleará mucho tiempo interactuando con su
   2.242 +programa de control de revisiones.
   2.243 +
   2.244 +Las herramientas distribuidas son indiferentes a los caprichos de su
   2.245 +infraestructura de servidores, de nuevo, debido a la replicación de
   2.246 +metadatos en tantos lugares. Si usa un sistema centralizado y su
   2.247 +servidor explota, ojalá los medios físicos de su copia de seguridad
   2.248 +sean confiables, y que su última copia sea reciente y además
   2.249 +funcione. Con una herramienta distribuida tiene tantas copias de
   2.250 +seguridad disponibles como computadores de contribuidores.
   2.251 +
   2.252 +La confiabilidad de su red afectará las herramientas distribuidas de
   2.253 +una forma mucho menor que las herramientas centralizadas No puede
   2.254 +siquiera usar una herramienta centralizada sin conexión de red,
   2.255 +excepto con algunas órdenes muy limitadas. Con herramientas
   2.256 +distribuidas, si sus conexión cae mientras usted está trabajando,
   2.257 +podría nisiquiera darse cuenta. Lo único que que no podrá hacer es
   2.258 +comunicarse  con repositorios en otros computadores, algo que es
   2.259 +relativamente raro comparado con las operaciones locales. Si tiene
   2.260 +colaboradores remotos en su equipo, puede ser significante.
   2.261 +
   2.262 +\subsection{Ventajas para proyectos de código abierto}
   2.263 +
   2.264 +Si descubre un proyecto de código abierto y decide que desea comenzar
   2.265 +a trabajar en él, y ese proyecto usa una herramienta de control
   2.266 +distribuido de revisiones, usted es un par con la gente que se
   2.267 +considera el ``alma'' del proyecto.  Si ellos publican los
   2.268 +repositorios, se puede copiar inmediatamente la historia del proyecto,
   2.269 +hacer cambios y guardar su trabajo, usando las mismas herramientas de
   2.270 +la misma forma que ellos. En contraste, con una herramienta
   2.271 +centralizada, debe usar el programa en un modo ``sólo lectura'' a
   2.272 +menos que alguien le otorgue permisos para consignar cambios en el
   2.273 +repositorio central. Hasta entonces, no podrá almacenar sus cambios y
   2.274 +sus modificaciones locales correrán el riesgo de dañarse cuando trate
   2.275 +de actualizar su vista del repositorio.
   2.276 +
   2.277 +\subsubsection{Las bifurcaciones(forks) no son un problema}
   2.278 +
   2.279 +Se ha mencionado que las herramientas de control distribuido de
   2.280 +versiones albergan un riesgo a los proyectos de código abierto, puesto
   2.281 +que se vuelve muy sencillo hacer una ``bifurcanción''\NdT{fork} del
   2.282 +desarrollo del proyecto.  Una bifurcación pasa cuando hay diferencias
   2.283 +de opinión o actitud entre grupos de desarrolladores que desenvoca en
   2.284 +la decisión de la imposibilidad de continuar trabajando juntos. Cada
   2.285 +parte toma una copia más o menos completa del código fuente del
   2.286 +proyecto y toma su propio rumbo.
   2.287 +
   2.288 +En algunas ocasiones los líderes de las bifurcaciones reconcilian sus
   2.289 +diferencias. Con un sistema centralizado de control de revisiones, el
   2.290 +proceso \emph{técnico} de reconciliarse es doloroso, y se hace de
   2.291 +forma muy manual.  Tiene que decidir qué historia de revisiones va a
   2.292 +``win'', e injertar los cambios del otro equipo en el árbol de alguna
   2.293 +manera. Con esto usualmente se pierde algo o todo del historial de la
   2.294 +revisión de alguna de las partes.
   2.295 +
   2.296 +Lo que las herramientas distribuidas hacen con respecto a las
   2.297 +bifurcaciones, es que las bifurcaciones son la \emph{única} forma de
   2.298 +desarrollar un proyecto. Cada cambio que usted hace es potencialmente
   2.299 +un punto de bifurcación. La gran fortaleza de esta aproximación es que
   2.300 +las herramientas distribuidas de control de revisiones tiene que ser
   2.301 +bueno al \emph{fusionar} las bifurcaciones, porque las bifurcaciones
   2.302 +son absolutamente fundamentales: pasan todo el tiempo.
   2.303 +
   2.304 +Si todas las porciones de trabajo que todos hacen todo el tiempo, se
   2.305 +enmarca en términos de bifurcaciones y fusiones, entonces a aquello a
   2.306 +lo que se refiere en el mundo del código abierto a una ``bifurcación''
   2.307 +se convierte \emph{puramente} en una cuestión social. Lo que hacen las
   2.308 +herramientas distribuidas es \emph{disminuir} la posibilidad de una
   2.309 +bifurcación porque:
   2.310  \begin{itemize}
   2.311 -\item They eliminate the social distinction that centralised tools
   2.312 -  impose: that between insiders (people with commit access) and
   2.313 -  outsiders (people without).
   2.314 -\item They make it easier to reconcile after a social fork, because
   2.315 -  all that's involved from the perspective of the revision control
   2.316 -  software is just another merge.
   2.317 +\item Eliminan la distinción social que las herramientas centralizadas
   2.318 +  imponen: esto entre los miembros (personas con permiso de consignar)
   2.319 +  y forasteros(los que no tienen el permiso).
   2.320 +\item Facilitan la reconciliación después de una bifurcación social,
   2.321 +  porque todo lo que concierne al programa de control de revisiones es
   2.322 +  una fusión.
   2.323  \end{itemize}
   2.324  
   2.325 -Some people resist distributed tools because they want to retain tight
   2.326 -control over their projects, and they believe that centralised tools
   2.327 -give them this control.  However, if you're of this belief, and you
   2.328 -publish your CVS or Subversion repositories publically, there are
   2.329 -plenty of tools available that can pull out your entire project's
   2.330 -history (albeit slowly) and recreate it somewhere that you don't
   2.331 -control.  So while your control in this case is illusory, you are
   2.332 -forgoing the ability to fluidly collaborate with whatever people feel
   2.333 -compelled to mirror and fork your history.
   2.334 +Algunas personas se resisten a las herramientas distribuidas porque
   2.335 +desean mantener control completo sobre sus proyectos, y creen que las
   2.336 +herramientas centralizadas les dan tal control. En todo caso, si este
   2.337 +es su parecer, y publica sus repositorios de CVS o Subversion, hay
   2.338 +muchas herramientas disponibles que pueden obtener la historia
   2.339 +completa(A pesar de lo lento) y recrearla en otro sitio que usted no
   2.340 +controla. Siendo así un control ilusorio, está impidiendo la fluidez
   2.341 +de colaboración frente a quien se sienta impulsado a obtener una copia
   2.342 +y hacer una bifurcación con su historia.
   2.343  
   2.344  \subsection{Advantages for commercial projects}
   2.345