1.1 --- a/es/Leame.1st	Mon Jan 12 16:46:25 2009 -0500
     1.2 +++ b/es/Leame.1st	Mon Jan 12 19:45:41 2009 -0500
     1.3 @@ -125,7 +125,7 @@
     1.4  || undo.tex       || Javier Rojas  ||            ||            ||             ||
     1.5  || tour-merge.tex ||               ||            ||            ||             ||
     1.6  || concepts.tex   ||               ||            ||            ||             ||
     1.7 -|| intro.tex      ||               ||            ||            ||             ||
     1.8 +|| intro.tex      || Javier Rojas  ||    100%    || 12/01/2009 ||  12/01/2009 ||
     1.9  || collab.tex     || Javier Rojas  ||            ||            ||             ||
    1.10  || mq.tex         ||               ||            ||            ||             ||
    1.11  || hgext.tex      ||               ||            ||            ||             ||

     2.1 --- a/es/intro.tex	Mon Jan 12 16:46:25 2009 -0500
     2.2 +++ b/es/intro.tex	Mon Jan 12 19:45:41 2009 -0500
     2.3 @@ -6,10 +6,10 @@
     2.4  El control de revisiones es el proceso de administrar diferentes
     2.5  versiones de una pieza de información. En su forma más simple es algo
     2.6  que la mayoría de gente hace a mano: cada vez que usted modifica un
     2.7 -fichero, lo graba con un nuevo nombre que contiene un número, el
     2.8 -siguiente mayor que el anterior.
     2.9 -
    2.10 -Administrar manualmente muchas versiones de un fichero es una tarea
    2.11 +fichero, lo graba con un nuevo nombre que contiene un número, cada uno
    2.12 +mayor que el anterior.
    2.13 +
    2.14 +Administrar manualmente muchas versiones de incluso sólo un fichero es una tarea
    2.15  propensa a errores, a pesar de que hace bastante tiempo hay
    2.16  herramientas que ayudan en este proceso.  Las primeras herramientas
    2.17  para automatizar el control de revisiones fueron pensadas para que un
    2.18 @@ -18,7 +18,7 @@
    2.19  considerablemente; ahora manejan muchos ficheros y facilitan el
    2.20  trabajo en conjunto de varias personas. Las mejores herramientas de
    2.21  control de revisiones de la actualidad no tienen problema con miles de
    2.22 -personas trabajando en proyectos que consisten de decenas de miles de
    2.23 +personas trabajando en proyectos que consisten de cientos de miles de
    2.24  ficheros.
    2.25  
    2.26  \subsection{¿Por qué usar control de revisiones?}
    2.27 @@ -26,36 +26,37 @@
    2.28  Hay muchas razones por las cuales usted o su equipo desearía usar una
    2.29  herramienta automática de control de revisiones para un proyecto.
    2.30  \begin{itemize}
    2.31 -\item Contar con la historia y la evolución de su proyecto, para
    2.32 -  evitar hacer la tarea manualmente. Por cada cambio tendrá una
    2.33 +        %TODO historia
    2.34 +\item Llevar registro de la historia y la evolución de su proyecto, para
    2.35 +  evitar hacer la tarea manualmente. Por cada cambio, tendrá una
    2.36    bitácora de \emph{quién} lo hizo; \emph{por qué} se hizo;
    2.37    \emph{cuándo} se hizo; y de \emph{qué} se trataba el cambio.
    2.38  \item Cuando trabaja con más personas, los programas de control de
    2.39    revisiones facilitan la colaboración.  Por ejemplo, cuando varias
    2.40 -  personas de forma casi simultanea pueden hacer cambios
    2.41 -  incompatibles, el programa le ayudará a identificar y resolver tales
    2.42 +  personas hacen cambios potencialmente incompatibles de forma casi
    2.43 +  simultánea, el programa le ayudará a identificar y resolver tales
    2.44    conflictos.
    2.45  \item Puede ayudarle a recuperarse de equivocaciones. Si aplica un
    2.46    cambio que posteriormente se evidencia como un error, puede
    2.47    revertirlo a una versión previa a uno o muchos ficheros. De hecho,
    2.48    una herramienta \emph{realmente} buena, incluso puede ayudarle
    2.49    efectivamente a darse cuenta exactamente cuándo se introdujo el
    2.50 -  error( para más detalles ver la sección~\ref{sec:undo:bisect}).
    2.51 -\item Le permitirá trabajar simultáneamente, y manejar las diferencias
    2.52 +  error (para más detalles ver la sección~\ref{sec:undo:bisect}).
    2.53 +\item Le ayudará a trabajar simultáneamente, y a manejar las diferencias
    2.54    entre múltiples versiones de su proyecto.
    2.55  \end{itemize}
    2.56  La mayoría de estas razones son igualmente válidas ---por lo menos en
    2.57 -teoría--- así esté trabajando en un proyecto solo, o con mucha gente.
    2.58 +teoría--- así esté trabajando en un proyecto solo usted, o con mucha gente.
    2.59  
    2.60  Algo fundamental acerca de lo práctico de un sistema de control de
    2.61 -revisiones en estas dos escalas (``un hacker solo'' y ``un equipo
    2.62 +revisiones en estas dos escalas (``un hacker solitario'' y ``un equipo
    2.63  gigantesco'') es cómo se comparan los \emph{beneficios} con los
    2.64  \emph{costos}.  Una herramienta de control de revisiones que sea
    2.65  difícil de entender o usar impondrá un costo alto.
    2.66  
    2.67  Un proyecto de quinientas personas es muy propenso a colapsar
    2.68 -solamente con su peso inmediatamente sin una herramienta de control de
    2.69 -versiones y un proceso. En este caso, el costo de usar control de
    2.70 +solamente con su peso inmediatamente sin una herramienta y un proceso
    2.71 +de control de versiones. En este caso, el costo de usar control de
    2.72  revisiones ni siquiera se tiene en cuenta, puesto que \emph{sin} él,
    2.73  el fracaso está casi garantizado.
    2.74  
    2.75 @@ -64,26 +65,25 @@
    2.76  casi seguramente, el costo de usar una estaría cerca del costo del
    2.77  proyecto. ¿No es así?
    2.78  
    2.79 -%TODO el sentido de uniquely va más a decir que hace ambas cosas sin problema,
    2.80 -% no a que ``apenas''las soporta, no?
    2.81 -Mercurial solamente soporta \emph{ambas} escalas de de
    2.82 -desarrollo. Puede aprender lo básico en pocos minutos, y dado su bajo
    2.83 +Mercurial soporta \emph{ambas} escalas de de desarrollo de manera
    2.84 +única. Puede aprender lo básico en pocos minutos, y dado su bajo
    2.85  sobrecosto, puede aplicar el control de revisiones al proyecto más
    2.86  pequeño con facilidad. Su simplicidad significa que no tendrá que
    2.87  preocuparse por conceptos obtusos o secuencias de órdenes compitiendo
    2.88  por espacio mental con lo que sea que \emph{realmente} esté tratando
    2.89  de hacer.  Al mismo tiempo, Mercurial tiene alto desempeño y su
    2.90 +%TODO distribuida? en vez de p2p
    2.91  naturaleza peer-to-peer le permite escalar indoloramente para manejar
    2.92  grandes proyectos.
    2.93  
    2.94  Ninguna herramienta de control de revisiones puede salvar un
    2.95  proyecto mal administrado, pero la elección de herramientas puede
    2.96 -hacer una gran diferencia en la fluidez con la cual puede trabajar en
    2.97 -el proyecto.
    2.98 +hacer una gran diferencia en la fluidez con la cual usted puede
    2.99 +trabajar en un proyecto.
   2.100  
   2.101  \subsection{La cantidad de nombres del control de revisiones}
   2.102  
   2.103 -El control de revisiones es un campo amplio, tan ampli que no hay un
   2.104 +El control de revisiones es un campo amplio, tan amplio que no hay un
   2.105  acrónimo o nombre único. A continuación presentamos un listado de
   2.106  nombres comunes y acrónimos que se podrían encontrar:
   2.107  \begin{itemize}
   2.108 @@ -95,8 +95,8 @@
   2.109  \item Control de Versiones(VCS)
   2.110  \end{itemize}
   2.111  Algunas personas aducen que estos términos tienen significados
   2.112 -diversos, pero en la práctica se sobrelapan tanto que no hay un
   2.113 -acuerdo o una forma adecuada de separarlos.
   2.114 +diversos, pero en la práctica se sobrelapan tanto que no hay una
   2.115 +forma acordada o incluso adecuada de separarlos.
   2.116  
   2.117  \section{Historia resumida del control de revisiones}
   2.118  
   2.119 @@ -112,30 +112,31 @@
   2.120  modificar los ficheros en cuestión sin la intervención del
   2.121  administrador.
   2.122  
   2.123 -Walter Tichy desarrolló una alternativa gratutita a SCCS a comienzos
   2.124 -de los ochentas(1980s), llamó a su programa RCS(Sistema de Control de
   2.125 +Walter Tichy desarrolló una alternativa gratuita a SCCS a comienzos
   2.126 +de los ochentas(1980s); llamó a su programa RCS (Sistema de Control de
   2.127  Revisiones).  Al igual que SCCS, RCS requería que los desarrolladores
   2.128  trabajaran en un único espacio compartido y colocaran candados a los
   2.129 -ficheros para evitar que varias personas los estuvieran modificando
   2.130 +ficheros para evitar que varias personas los modificaran
   2.131  simultáneamente.
   2.132  
   2.133  Después en los ochenta, Dick Grune usó RCS como un bloque de
   2.134  construcción para un conjunto de guiones de línea de comando, que
   2.135 -inicialmente llamó cmt, pero que renombró a CVS(Sistema Concurrente de
   2.136 +inicialmente llamó cmt, pero que renombró a CVS (Sistema Concurrente de
   2.137  Versiones).  La gran innovación de CVS era que permitía a los
   2.138  desarrolladores trabajar simultáneamente de una forma más o menos
   2.139  independiente en sus propios espacios de trabajo. Los espacios de
   2.140 -trabajo personales impedian que los desarrolladores se pisaran las
   2.141 +trabajo personales impedían que los desarrolladores se pisaran las
   2.142  mangueras todo el tiempo, situación común con SCCS y RCS.  Cada
   2.143 -desarrollador tenía una copia de todo el fichero del proyecto y podía
   2.144 -modificar su copia independientemente, Tenían que fusionar sus
   2.145 +desarrollador tenía una copia de todos los ficheros del proyecto y podía
   2.146 +modificar sus copias independientemente, Tenían que fusionar sus
   2.147  ediciones antes de consignar los cambios al repositorio central.
   2.148  
   2.149  Brian Berliner tomó los scripts originales de Grune y los reescribió
   2.150 -en~C, haciéndolos públicos en 1989, código sobre el cual se ha
   2.151 -desarrollado la versión moderna de CVS.  CVS posteriormente adquirió
   2.152 +en~C, publicando en 1989 el código sobre el cual se ha
   2.153 +desarrollado la versión moderna de CVS.  CVS adquirió posteriormente 
   2.154  la habilidad de operar sobre una conexión de red, dotándolo de una
   2.155  arquitectura, cliente/servidor. La arquitectura de CVS es
   2.156 +%TODO historia/historial
   2.157  centralizada; La historia del proyecto está únicamente en el
   2.158  repositorio central.  Los espacios de trabajo de los clientes
   2.159  contienen únicamente copias recientes de las versiones de los
   2.160 @@ -143,36 +144,37 @@
   2.161  ha tenido un éxito enorme; Es probablemente el sistema de control de
   2.162  revisiones más extendido del planeta.
   2.163  
   2.164 -A comienzos de los noventa(1990s), Sun MicroSystems desarrollo un
   2.165 -temprano sistema distribuido de revisión de controles llamado TeamWare
   2.166 +A comienzos de los noventa~(1990s), Sun MicroSystems desarrollo un
   2.167 +temprano sistema distribuido de control de revisiones llamado
   2.168 +TeamWare.
   2.169  Un espacio de trabajo TeamWare contiene una copia completa de la
   2.170  historia del proyecto. TeamWare no tiene la noción de repositorio
   2.171  central. (CVS se basaba en RCS para el almacenamiento de su historia;
   2.172  TeamWare usaba SCCS.)
   2.173  
   2.174 -A medida que avanzaba la decada de los noventa, se empezño a
   2.175 -evidenciar los problemas de CVS.  Alacena cambios simultáneos a muchos
   2.176 +A medida que avanzaba la decada de los noventa, se empezó a
   2.177 +evidenciar los problemas de CVS.  Almacena cambios simultáneos a muchos
   2.178  ficheros de forma individual, en lugar de agruparlos como una
   2.179  operación única y atómica lógicamente.  No maneja bien su jerarquía de
   2.180 -ficheros bien; es fácil desordenar un repositorio renombrando ficheros
   2.181 +ficheros; es fácil desordenar un repositorio al renombrar ficheros
   2.182  y directorios. Peor aún, su código fuente es difícil de leer y
   2.183 -mantener, lo que hace que su ``umbral de dolor'' para arreglar sus
   2.184 -problemas arquitecturales algo prohibitivo.
   2.185 +mantener, lo que hizo que su ``umbral de dolor'' para arreglar sus
   2.186 +problemas arquitecturales fuera algo prohibitivo.
   2.187  
   2.188  En 2001, Jim Blandy y Karl Fogel, dos desarrolladores que habían
   2.189  trabajado en CVS, comenzaron un proyecto para reemplazarlo con una
   2.190  herramienta con mejor arquitectura y código más limpio.  El resultado,
   2.191  Subversion, no se separó del modelo centralizado cliente/servidor de
   2.192  CVS, pero añadió consignaciones atómicas de varios ficheros, mejor
   2.193 -manejo de nombres de espacios, y otras características que lo hacen
   2.194 +manejo de espacios de nombres , y otras características que lo hacen
   2.195  mejor que CVS. Desde su versión inicial, ha ido creciendo en
   2.196 -popularidad.
   2.197 +popularidad rápidamente.
   2.198  
   2.199  Más o menos en forma simultánea Graydon Hoare comenzó a trabajar en un
   2.200 -sistema distribuido de control de versiones ambicioso que llamó
   2.201 +ambicioso sistema distribuido de control de versiones que llamó
   2.202  Monotone. Mientras que Monotone se enfocaba a evitar algunas fallas de
   2.203  diseño de CVS con una arquitectura peer-to-peer, fue mucho más
   2.204 -allá(junto con otros proyectos subsecuentes) que unas herramientas de
   2.205 +allá de las herramientas anteriores (y posteriores) de
   2.206  control de revisiones en varios aspectos innovadores. Usa hashes
   2.207  criptográficos como identificadores, y tiene una noción integral de 
   2.208  ``confianza'' para código de diversas fuentes.
   2.209 @@ -184,45 +186,47 @@
   2.210  
   2.211  \section{Tendencias en el control de revisiones}
   2.212  
   2.213 -Ha habido varias tendencias en el desarrollo y uso de las herramientas
   2.214 -de control de revisiones en las pasadas cuatro décadas, mientras la
   2.215 -gente se ha vuelto familiar con las capacidades de sus herramientas
   2.216 -así mismo con sus limitaciones.
   2.217 +Ha habido una tendencia inconfundible en el desarrollo y uso de las herramientas
   2.218 +de control de revisiones en las cuatro décadas pasadas, mientras la
   2.219 +gente se ha hecho familiar con las capacidades de sus herramientas y
   2.220 +se ha visto restringida por sus limitaciones.
   2.221  
   2.222  La primera generación comenzó administrando ficheros individuales en
   2.223  computadores por persona. A pesar de que tales herramientas
   2.224  representaron un avance importante frente al control de revisiones
   2.225 -manual, su modelo de candados y la limitación a un sólo computador,
   2.226 -determinó equipos de trabajo pequeños y acoplados.
   2.227 +manual, su modelo de candados y la dependencia a un sólo computador
   2.228 +los limitó a equipos de trabajo pequeños y acoplados.
   2.229  
   2.230  La segunda generación dejó atrás esas limitaciones moviéndose a
   2.231  arquitecturas centradas en  redes, y administrando proyectos completos
   2.232 -uno a la vez. A medida que los proyectos crecían, nacieron nuevos
   2.233 +a la vez. A medida que los proyectos crecían, nacieron nuevos
   2.234  problemas. Con la necesidad de comunicación frecuente con los
   2.235  servidores, escalar estas máquinas se convirtió en un problema en
   2.236 -proyectos realmente grandes. Las redes con poca estabilidad impidieron
   2.237 -que usuarios remotos se conectaran al servidor. A medida que los
   2.238 -proyecos de código abierto comenzaron a ofrecer acceso de sólo lectura
   2.239 -de forma anónima a cualquiera, la gente sin permiso para consignar,
   2.240 +proyectos realmente grandes. Las redes con poca estabilidad podrían
   2.241 +impedir que usuarios remotos se conectaran al servidor. A medida que
   2.242 +los
   2.243 +proyectos de código abierto comenzaron a ofrecer acceso de sólo lectura
   2.244 +de forma anónima a cualquiera, la gente sin permiso para consignar
   2.245  vio que no podían usar tales herramientas para interactuar en un
   2.246  proyecto de forma natural, puesto que no podían guardar sus cambios.
   2.247  
   2.248 -La generación actual de herramientas de control de revisiones es de
   2.249 -forma natural peer-to-peer.  Todos estos sistemas han eliminado la
   2.250 +La generación actual de herramientas de control de revisiones es
   2.251 +peer-to-peer por naturaleza.  Todos estos sistemas han eliminado la
   2.252  dependencia de un único servidor central, y han permitido que la
   2.253  gente distribuya sus datos de control de revisiones donde realmente se
   2.254  necesita. La colaboración a través de Internet ha cambiado las
   2.255 -limitantes tecnológicas a la cuestión de elección y consenso. Las
   2.256 -herramientas modernas pueden operar sin conexión indefinidamenta y
   2.257 +limitantes tecnológicas por la cuestión de elección y consenso. Las
   2.258 +herramientas modernas pueden operar sin conexión indefinidamente y
   2.259  autónomamente, necesitando una conexión de red solamente para
   2.260  sincronizar los cambios con otro repositorio.
   2.261  
   2.262  \section{Algunas ventajas del control distribuido de revisiones}
   2.263  
   2.264  A pesar de que las herramientas para el control distribuido de
   2.265 -revisiones lleva varios años siendo tan robusto y usable como la
   2.266 -generación previa de su contraparte, personas que usan herramientas
   2.267 -más antiguas no se han percatado de sus ventajas.  Hay gran cantidad
   2.268 +revisiones lleva varios años siendo tan robustas y usables como la
   2.269 +generación previa de sus contrapartes, algunas personas que usan las
   2.270 +herramientas más antiguas no se han percatado de sus ventajas.  Hay
   2.271 +gran cantidad
   2.272  de situaciones en las cuales las herramientas distribuidas brillan
   2.273  frente a las centralizadas.
   2.274  
   2.275 @@ -246,37 +250,38 @@
   2.276  seguridad disponibles como computadores de contribuidores.
   2.277  
   2.278  La confiabilidad de su red afectará las herramientas distribuidas de
   2.279 -una forma mucho menor que las herramientas centralizadas No puede
   2.280 +una forma mucho menor que a las herramientas centralizadas. Usted no puede
   2.281  siquiera usar una herramienta centralizada sin conexión de red,
   2.282 -excepto con algunas órdenes muy limitadas. Con herramientas
   2.283 +excepto por algunas órdenes muy limitadas. Con herramientas
   2.284  distribuidas, si sus conexión cae mientras usted está trabajando,
   2.285  podría nisiquiera darse cuenta. Lo único que que no podrá hacer es
   2.286  comunicarse  con repositorios en otros computadores, algo que es
   2.287  relativamente raro comparado con las operaciones locales. Si tiene
   2.288 -colaboradores remotos en su equipo, puede ser significante.
   2.289 +colaboradores remotos en su equipo, puede ser importante.
   2.290  
   2.291  \subsection{Ventajas para proyectos de código abierto}
   2.292  
   2.293  Si descubre un proyecto de código abierto y decide que desea comenzar
   2.294  a trabajar en él, y ese proyecto usa una herramienta de control
   2.295 -distribuido de revisiones, usted es un par con la gente que se
   2.296 -considera el ``alma'' del proyecto.  Si ellos publican los
   2.297 -repositorios, se puede copiar inmediatamente la historia del proyecto,
   2.298 +distribuido de revisiones, usted es de inmediato un par con la gente que se
   2.299 +considera el ``alma'' del proyecto.  Si ellos publican sus
   2.300 +%TODO historia/historial
   2.301 +repositorios, usted puede copiar inmediatamente la historia del proyecto,
   2.302  hacer cambios y guardar su trabajo, usando las mismas herramientas de
   2.303  la misma forma que ellos. En contraste, con una herramienta
   2.304 -centralizada, debe usar el programa en un modo ``sólo lectura'' a
   2.305 +centralizada, usted debe usar el programa en un modo ``sólo lectura'' a
   2.306  menos que alguien le otorgue permisos para consignar cambios en el
   2.307  repositorio central. Hasta entonces, no podrá almacenar sus cambios y
   2.308  sus modificaciones locales correrán el riesgo de dañarse cuando trate
   2.309  de actualizar su vista del repositorio.
   2.310  
   2.311 -\subsubsection{Las bifurcaciones(forks) no son un problema}
   2.312 +\subsubsection{Las bifurcaciones (forks) no son un problema}
   2.313  
   2.314  Se ha mencionado que las herramientas de control distribuido de
   2.315  versiones albergan un riesgo a los proyectos de código abierto, puesto
   2.316 -que se vuelve muy sencillo hacer una ``bifurcanción''\ndt{fork.} del
   2.317 -desarrollo del proyecto.  Una bifurcación pasa cuando hay diferencias
   2.318 -de opinión o actitud entre grupos de desarrolladores que desenvoca en
   2.319 +que se vuelve muy sencillo hacer una ``bifurcación''\ndt{fork.} del
   2.320 +desarrollo del proyecto.  Una bifurcación sucede cuando hay diferencias
   2.321 +de opinión o actitud entre grupos de desarrolladores que desemboca en
   2.322  la decisión de la imposibilidad de continuar trabajando juntos. Cada
   2.323  parte toma una copia más o menos completa del código fuente del
   2.324  proyecto y toma su propio rumbo.
   2.325 @@ -284,8 +289,10 @@
   2.326  En algunas ocasiones los líderes de las bifurcaciones reconcilian sus
   2.327  diferencias. Con un sistema centralizado de control de revisiones, el
   2.328  proceso \emph{técnico} de reconciliarse es doloroso, y se hace de
   2.329 -forma muy manual.  Tiene que decidir qué historia de revisiones va a
   2.330 -``win'', e injertar los cambios del otro equipo en el árbol de alguna
   2.331 +%TODO historia/historial
   2.332 +forma muy manual.  Usted tiene que decidir qué historia de revisiones va a
   2.333 +``ganar'', e injertar los cambios del otro equipo en el árbol de alguna
   2.334 +%TODO historia/historial
   2.335  manera. Con esto usualmente se pierde algo o todo del historial de la
   2.336  revisión de alguna de las partes.
   2.337  
   2.338 @@ -297,16 +304,16 @@
   2.339  bueno al \emph{fusionar} las bifurcaciones, porque las bifurcaciones
   2.340  son absolutamente fundamentales: pasan todo el tiempo.
   2.341  
   2.342 -Si todas las porciones de trabajo que todos hacen todo el tiempo, se
   2.343 -enmarca en términos de bifurcaciones y fusiones, entonces a aquello a
   2.344 +Si todas las porciones de trabajo que todos hacen, todo el tiempo, se
   2.345 +enmarcan en términos de bifurcaciones y fusiones, entonces a aquello a
   2.346  lo que se refiere en el mundo del código abierto a una ``bifurcación''
   2.347  se convierte \emph{puramente} en una cuestión social. Lo que hacen las
   2.348  herramientas distribuidas es \emph{disminuir} la posibilidad de una
   2.349  bifurcación porque:
   2.350  \begin{itemize}
   2.351 -\item Eliminan la distinción social que las herramientas centralizadas
   2.352 -  imponen: esto entre los miembros (personas con permiso de consignar)
   2.353 -  y forasteros(los que no tienen el permiso).
   2.354 +\item Eliminan la distinción social que imponen las herramientas
   2.355 +  centralizadas: aquélla entre miembros (personas con permiso de
   2.356 +  consignar) y forasteros (los que no tienen el permiso).
   2.357  \item Facilitan la reconciliación después de una bifurcación social,
   2.358    porque todo lo que concierne al programa de control de revisiones es
   2.359    una fusión.
   2.360 @@ -314,10 +321,10 @@
   2.361  
   2.362  Algunas personas se resisten a las herramientas distribuidas porque
   2.363  desean mantener control completo sobre sus proyectos, y creen que las
   2.364 -herramientas centralizadas les da tal control. En todo caso, si este
   2.365 -es su parecer, y publica sus repositorios de CVS o Subversion, hay
   2.366 +herramientas centralizadas les dan tal control. En todo caso, si este
   2.367 +es su parecer, y usted publica sus repositorios de CVS o Subversion, hay
   2.368  muchas herramientas disponibles que pueden obtener la historia
   2.369 -completa(A pesar de lo lento) y recrearla en otro sitio que usted no
   2.370 +completa (aunque sea lentamente) y recrearla en otro sitio que usted no
   2.371  controla. Siendo así un control ilusorio, puesto que está impidiendo
   2.372  la fluidez de colaboración en lugar de prevenir que alguien se sienta
   2.373  impulsado a obtener una copia y hacer una bifurcación con su historia.
   2.374 @@ -326,38 +333,38 @@
   2.375  
   2.376  Muchos proyectos comerciales tienen grupos de trabajo distribuidos
   2.377  alrededor del globo.  Quienes contribuyen y están lejos de un
   2.378 -repositorio central verán una ejecución más lenta de las órdenes y tal
   2.379 +repositorio central verán una ejecución más lenta de los comandos y tal
   2.380  vez menos confiabilidad. Los sistemas de control de revisión
   2.381  comerciales intentan amortiguar estos problemas con adiciones de
   2.382  replicación remota que usualmente son muy costosos y complicados de
   2.383 -administradr. Un sistema distribuido no padece estos problemas. Mejor
   2.384 +administrar. Un sistema distribuido no padece estos problemas. Mejor
   2.385  aún, puede colocar varios servidores autorizados, por ejemplo, uno por
   2.386  sitio, de tal forma que no haya comunicación redundante entre
   2.387  repositorios sobre enlaces de conexión costosos.
   2.388  
   2.389  Los sistemas de control de revisiones distribuidos tienden a ser poco
   2.390 -escalables. No es inusual quw costosos sistemas centralizados caigan
   2.391 +escalables. No es inusual que costosos sistemas centralizados caigan
   2.392  ante la carga combinada de unas cuantas docenas de usuarios
   2.393 -concurrentes. De nuevo, las respuestas típicas de replibcación tienden
   2.394 +concurrentes. De nuevo, las respuestas típicas de replicación tienden
   2.395  a ser costosas y complejas de instalar y administrar. Dado que la
   2.396  carga en un servidor central---si es que tiene uno---es muchas veces
   2.397 -menor con una herramienta distribuida(debido a que los datos están
   2.398 -replicados en todas partes), un sólo servidor económico puede tratar
   2.399 +menor con una herramienta distribuida (debido a que los datos están
   2.400 +replicados en todas partes), un solo servidor económico puede tratar
   2.401  las necesidades de equipos mucho más grandes, y la replicación para
   2.402 -balancear la carga se vuelve cosa de scripts.
   2.403 +balancear la carga se vuelve cosa de guiones.
   2.404  
   2.405  Si tiene un empleado en el campo, se beneficiará grandemente de un
   2.406  sistema distribuido de control de versiones al resolver problemas en
   2.407  el sitio del cliente. La herramienta le permitirá generar
   2.408  construcciones a la medida, probar diferentes arreglos de forma
   2.409  independiente y buscar de forma eficiente las fuentes de fallos en la
   2.410 -historia y regresiones en los ambientes de los clientes, todo, sin
   2.411 +historia y regresiones en los ambientes de los clientes, todo sin
   2.412  necesidad de conectarse al servidor de su compañía.
   2.413  
   2.414  \section{¿Por qué elegir Mercurial?}
   2.415  
   2.416  Mercurial cuenta con un conjunto único de propiedades que lo hacen
   2.417 -particularmente una buena elección como un sistema de control de
   2.418 +una elección particularmente buena como sistema de control de
   2.419  revisiones, puesto que:
   2.420  \begin{itemize}
   2.421  \item Es fácil de aprender y usar.
   2.422 @@ -367,14 +374,14 @@
   2.423  \end{itemize}
   2.424  
   2.425  Si los sistemas de control de revisiones le son familiares, debería
   2.426 -estar listo para usar Mercurial en menos de cinco minutos. Si no, va a
   2.427 +estar listo para usar Mercurial en menos de cinco minutos. Si no, sólo va a
   2.428  tomar unos pocos minutos más. Las órdenes de Mercurial y su conjunto
   2.429  de características son uniformes y consistentes generalmente, y basta
   2.430  con que siga unas pocas reglas generales en lugar de un montón de
   2.431  excepciones.
   2.432  
   2.433 -En un proyecto pequeño, puede comenzar a trabajar con Mercurial poco a
   2.434 -poco. Creando nuevos cambios y ramas, transfiriendo cambios(localmente
   2.435 +En un proyecto pequeño, usted puede comenzar a trabajar con Mercurial en
   2.436 +pocos momentos. Crear nuevos cambios y ramas, transferir cambios (localmente
   2.437  o por la red); y las operaciones relacionadas con el estado y la
   2.438  historia son rápidas. Mercurial buscar ser ligero y no incomodar en su
   2.439  camino combinando poca sobrecarga cognitiva con operaciones
   2.440 @@ -390,13 +397,12 @@
   2.441  scripting y su limpieza interna junto con su implementación en Python
   2.442  permiten añadir características fácilmente en forma de extensiones.
   2.443  Hay un buen número de extensiones útiles y populares en este momento,
   2.444 -desde ayudar a identificar fallos hasta el mejoramiento de su
   2.445 -desempeño.
   2.446 +desde ayudar a identificar fallos hasta mejorar su desempeño.
   2.447  
   2.448  \section{Comparación de Mercurial con otras herramientas}
   2.449  
   2.450  Antes de leer, por favor tenga en cuenta que esta sección
   2.451 -necesariamente refleja mis propias experiencias, intereses y(tengo que
   2.452 +necesariamente refleja mis propias experiencias, intereses y (tengo que
   2.453  decirlo) mis preferencias. He usado cada una de las herramientas de
   2.454  control de versiones listadas a continuación, y en muchos casos por
   2.455  varios años.
   2.456 @@ -405,10 +411,10 @@
   2.457  \subsection{Subversion}
   2.458  
   2.459  Subversion es una herramienta de control de revisiones muy popular,
   2.460 -desarrollada para reemplazar a CVS.  Su arquitectura es centralizada
   2.461 -en cliente/servidor.
   2.462 -
   2.463 -Subversion y Mercurial tienen órdenes con nombres similares para hacer
   2.464 +desarrollada para reemplazar a CVS.  Tiene una arquitectura
   2.465 +centralizada tipo cliente/servidor.
   2.466 +
   2.467 +Subversion y Mercurial tienen comandos con nombres similares para hacer
   2.468  las mismas operaciones, por lo que si le son familiares en una, será
   2.469  sencillo aprender a usar la otra. Ambas herramientas son portables en
   2.470  todos los sistemas operativos populares.
   2.471 @@ -419,20 +425,21 @@
   2.472  \href{http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword}{complicadas
   2.473    y poco estables\ndt{buggy}}.
   2.474  
   2.475 -Mercurial tiene una ventaja considerable en el desempeño sobre
   2.476 +Mercurial tiene una ventaja considerable en desempeño sobre
   2.477  Subversion en cualquier operación de control de revisiones que yo haya
   2.478  medido. He medido sus ventajas con factores desde dos hasta seis veces
   2.479  comparando con almacenamiento de ficheros \emph{ra\_local}
   2.480  Subversion~1.4.3, el cual es el método de acceso más rápido.  En los
   2.481 -escenarios más sencillos incluyendo almacenamiento con la red de por
   2.482 +escenarios más realistas incluyendo almacenamiento con la red de por
   2.483  medio, Subversion se encuentra en desventaja aún mayor. Dado que casi
   2.484  todas las órdenes de Subversion deben tratar con el servidor y
   2.485 -Subversion no tiene utilidades de replicación sencillas, la capacidad
   2.486 +Subversion no tiene utilidades de replicación adecuadas, la capacidad
   2.487  del servidor y el ancho de banda se convierten en cuellos de botella
   2.488  para proyectos modestamente grandes.
   2.489  
   2.490 -Adicionalmente, Subversion tiene un sobrecosto en almacentamiento
   2.491 -considerable para evitar transacciones por red en algunas operaciones,
   2.492 +Adicionalmente, Subversion tiene un sobrecosto considerable en
   2.493 +almacenamiento para evitar transacciones por red en algunas
   2.494 +operaciones,
   2.495  tales como encontrar ficheros modificados(\texttt{status}) y desplegar
   2.496  información frente a la revisión actual(\texttt{diff}).  Como
   2.497  resultado, la copia de trabajo de Subversion termina siendo del mismo
   2.498 @@ -473,11 +480,11 @@
   2.499  \subsection{Git}
   2.500  
   2.501  Git es una herramienta distribuida de control de revisiones
   2.502 -desarrollada para administrar el arbol del Kernel de Linux.  Al igual
   2.503 +desarrollada para administrar el arbol del kernel de Linux.  Al igual
   2.504  que Mercurial los principios de su diseño fueron influenciados por 
   2.505  Monotone.
   2.506  
   2.507 -Git tiene un conjunto de órdenes muy grande en la versión~1.5.0
   2.508 +Git tiene un conjunto de órdenes muy grande; en la versión~1.5.0
   2.509  ofrece~139 órdenes individuales.  Tiene cierta reputación de ser
   2.510  difícil de aprender. Comparado con Git, Mercurial tiene un fuerte
   2.511  enfoque hacia la facilidad.
   2.512 @@ -486,24 +493,24 @@
   2.513  casos, es más rápido que Mercurial, por lo menos en Linux, mientras
   2.514  que Mercurial se comporta mejor en otras operaciones.  De todas
   2.515  maneras en Windows, el desempeño y el nivel general de soporte que
   2.516 -ofrece Git, al momento de la escritura, está lejos detrás de
   2.517 +ofrece Git, al momento de la escritura, está bastante atrás de
   2.518  Mercurial.
   2.519  
   2.520  Mientras que el repositorio de Mercurial no requiere mantenimiento, el
   2.521 -repositorio de Git requiere frecuentes ``repacks'' a sus metadatos.
   2.522 -Sin estos, el desempeño se degrada y el espacio crece rápidamente. Un
   2.523 +repositorio de Git requiere frecuentes ``reempaquetados'' de sus metadatos.
   2.524 +Sin estos, el desempeño se degrada y el uso de espacio crece rápidamente. Un
   2.525  servidor que contenga repositorios de Git que no sean reempacados
   2.526 -rigurosa y frecuentemente requerirá trabajo-intenso de disco durante
   2.527 +rigurosa y frecuentemente requerirá trabajo intenso de disco durante
   2.528  las copias de seguridad, y ha habido situaciones en copias de
   2.529 -seguridad diaria que toman más de 24 horas como resultado. Un
   2.530 +seguridad diaria que toman más de~24 horas como resultado. Un
   2.531  repositorio recién reempacado de Git es un poco más pequeño que un
   2.532  repositorio de Mercurial, pero un repositorio sin reempacar es varios
   2.533  órdenes de magnitud más grande.
   2.534  
   2.535  El corazón de Git está escrito en C.  Muchas órdenes de Git están
   2.536 -implementadas como scripts de shell o Perl y la calidad de esos
   2.537 -scripts varía ampliamente. He encontrado muchas situaciones en las
   2.538 -cuales los scripts no tuvieron en cuenta la presencia de errores que
   2.539 +implementadas como guiones de línea de comandos o de Perl y la calidad de esos
   2.540 +guiones varía ampliamente. He encontrado muchas situaciones en las
   2.541 +cuales los guiones no tuvieron en cuenta la presencia de errores que
   2.542  podrían haber sido fatales.
   2.543  
   2.544  Mercurial puede importar el historial de revisiones de un repositorio
   2.545 @@ -513,52 +520,54 @@
   2.546  
   2.547  CVS es probablemente la herramienta de control de revisiones más
   2.548  ampliamente usada en el planeta.  Debido a su edad y su poca pulcritud
   2.549 -nterna, ha sido ligeramente mantenido en muchos años.
   2.550 +interna, ha sido ligeramente mantenida en muchos años.
   2.551  
   2.552  Tiene una arquitectura centralizada cliente/servidor. No agrupa
   2.553 -cambios relacionadso en consignaciones atómicas, pemitiendo que con
   2.554 +cambios relacionados en consignaciones atómicas, pemitiendo que con
   2.555  facilidad la gente ``rompa la construcción'': una persona puede
   2.556  consignar exitósamente parte del cambio y estar bloqueada por la
   2.557  necesidad de una mezcla, forzando a otras personas a ver solamente una
   2.558  porción del trabajo que estaban buscando hacer.  Esto afecta también
   2.559 +%TODO historia/historial
   2.560  la forma como usted trabaja con la historia del proyecto. Si quiere
   2.561  ver todas las modificaciones que alguien hizo como parte de una tarea,
   2.562  necesitará inspeccionar manualmente las descripciones y las marcas de
   2.563 -tiempo de cambio de cada fichero involucrado(esto, si usted saber
   2.564 +tiempo de cambio de cada fichero involucrado (esto, si usted saber
   2.565  cuáles eran tales ficheros).
   2.566  
   2.567  CVS tiene una noción confusa de etiquetas y ramas que yo no trataría
   2.568  incluso de describir.  No soporta renombramiento de ficheros o
   2.569 -directorios de buena forma, facilitando el corromper un
   2.570 +directorios adecuadamente, facilitando el corromper un
   2.571  repositorio. Casi no tiene chequeo de consistencia interna, por lo
   2.572  tanto es casi imposible identificar por que o cómo se corrompió un
   2.573  repositorio. Yo no recomendaría un repositorio de CVS para proyecto
   2.574  alguno, ni existente ni nuevo.
   2.575  
   2.576  Mercurial puede importar la historia de revisiones de CVS.  De todas
   2.577 -maneras hay ciertos trucos para aplicar; los cuales también son
   2.578 -necesarios para cualquier herramienta importadora de historial de
   2.579 +maneras hay ciertas precauciones que aplican; las cuales también son
   2.580 +necesarias para cualquier herramienta importadora de historial de
   2.581  CVS. Debido a la falta de atomicidad de cambios y el no versionamiento
   2.582 -de la jerarquía del sistema de archivos, es imposible reconstruir la
   2.583 -completamente la historia de CVS acertadamente; hay cierto trabajo de
   2.584 +de la jerarquía del sistema de ficheros, es imposible reconstruir
   2.585 +completamente la historia de CVS con precisión; hay cierto trabajo de
   2.586  conjetura involucrado y los renombramientos tampoco se
   2.587  mostrarán. Debido a que gran parte de la administración avanzada de
   2.588  CVS tiene que hacerse manualmente y por lo tanto es proclive al error,
   2.589  es común que los importadores de CVS encuentren muchos problemas con
   2.590 -repositorios corruptos( marcas de tiempo totalmente desubicadas y
   2.591 -archivos que han permanecido con candados por más de una década son
   2.592 -dos de los problemas más interesantes de los que puedo retomar de mi
   2.593 +repositorios corruptos (marcas de tiempo totalmente desubicadas y
   2.594 +ficheros que han permanecido con candados por más de una década son
   2.595 +dos de los problemas menos interesantes de los que puedo retomar de mi
   2.596  experiencia personal).
   2.597  
   2.598 +%TODO historia/historial
   2.599  Mercurial puede importar la historia de revisiones de un repositorio
   2.600  CVS.
   2.601  
   2.602  \subsection{Herramientas comerciales}
   2.603  
   2.604  Perforce tiene una arquitectura centralizada cliente/servidor sin
   2.605 -almacenamiento de dato alguno en el lado del cliente. A diferencia de
   2.606 +almacenamiento de dato alguno de caché en el lado del cliente. A diferencia de
   2.607  las herramientas modernas de control de revisiones, Perforce requiere
   2.608 -que un usuario ejecute una orden para informar al servidor acerca de
   2.609 +que un usuario ejecute un comando para informar al servidor acerca de
   2.610  todo fichero que se vaya a editar.
   2.611  
   2.612  El rendimiento de Perforce es muy bueno para equipos pequeños, pero se
   2.613 @@ -569,7 +578,7 @@
   2.614  \subsection{Elegir una herramienta de control de revisiones}
   2.615  
   2.616  Con la excepción de CVS, toda las herramientas que se han listado
   2.617 -anteriormente tienen fortalezas que los hacen valiosos de acuerdo al
   2.618 +anteriormente tienen fortalezas únicas que las hacen valiosas de acuerdo al
   2.619  tipo de trabajo. No hay una única herramienta de control de revisiones
   2.620  que sea la mejor en todas las situaciones.
   2.621  
   2.622 @@ -592,8 +601,8 @@
   2.623  obtener los nuevos cambios que han sucedido después de la migración
   2.624  inicial.
   2.625  
   2.626 -A continuación presentamos las herramientas de revisiones que la
   2.627 -orden\hgext{convert} soporta:
   2.628 +A continuación presentamos las herramientas de revisiones que soporta
   2.629 +el comando \hgext{convert}:
   2.630  \begin{itemize}
   2.631  \item Subversion
   2.632  \item CVS
   2.633 @@ -606,11 +615,11 @@
   2.634  en paralelo antes de lanzarse a un migración total, sin arriesgarse a
   2.635  perder trabajo alguno.
   2.636  
   2.637 -La orden \hgxcmd{conver}{convert} es sencilla de usar. Basta con
   2.638 -apuntarla hacia la ruta o el URL del repositorio fuente, opcionalmente
   2.639 +El comando \hgxcmd{conver}{convert} es sencillo de usar. Basta con
   2.640 +apuntarlo hacia la ruta o el URL del repositorio fuente, opcionalmente
   2.641  darle el nombre del nombre del repositorio destino y comenzará a hacer
   2.642  su trabajo. Después de la conversión inicial, basta con invocar de
   2.643 -nuevo la orden para importar nuevos cambios.
   2.644 +nuevo el comando para importar cambios nuevos.
   2.645  
   2.646  
   2.647  %%% Local Variables: