1.1 --- a/es/Leame.1st	Sun Nov 09 23:50:07 2008 -0500
     1.2 +++ b/es/Leame.1st	Mon Nov 10 23:38:36 2008 -0500
     1.3 @@ -103,7 +103,7 @@
     1.4  || tour-merge.tex  || Javier Rojas  ||    100%    || 28/10/2008 ||  03/11/2008 ||
     1.5  || concepts.tex    || Javier Rojas  ||      7%    || 03/11/2008 ||             ||
     1.6  || intro.tex	   || Igor Támara   ||	  100%	  || 08/11/2008	||  09/11/2008 ||
     1.7 -|| collab.tex      || Igor Támara   ||      0%    || 10/11/2008 ||             ||
     1.8 +|| collab.tex      || Igor Támara   ||     10%    || 10/11/2008 ||             ||
     1.9  
    1.10  == Archivos en proceso de revisión ==
    1.11  ||'''archivo'''   || '''revisor''' ||'''Estado'''||'''Inicio'''||  '''Fin'''  ||
    1.12 @@ -162,6 +162,7 @@
    1.13   Revlog: Bitácora de revisiones
    1.14   Roll back: NO se traduce Ver más abajo
    1.15   Snapshot: instantánea
    1.16 + Sprint: sprint
    1.17   Tip: punta
    1.18   Update: actualización
    1.19  

     2.1 --- a/es/collab.tex	Sun Nov 09 23:50:07 2008 -0500
     2.2 +++ b/es/collab.tex	Mon Nov 10 23:38:36 2008 -0500
     2.3 @@ -1,206 +1,120 @@
     2.4 -\chapter{Collaborating with other people}
     2.5 +\chapter{Colaborar con otros}
     2.6  \label{cha:collab}
     2.7  
     2.8 -As a completely decentralised tool, Mercurial doesn't impose any
     2.9 -policy on how people ought to work with each other.  However, if
    2.10 -you're new to distributed revision control, it helps to have some
    2.11 -tools and examples in mind when you're thinking about possible
    2.12 -workflow models.
    2.13 -
    2.14 -\section{Mercurial's web interface}
    2.15 -
    2.16 -Mercurial has a powerful web interface that provides several 
    2.17 -useful capabilities.
    2.18 -
    2.19 -For interactive use, the web interface lets you browse a single
    2.20 -repository or a collection of repositories.  You can view the history
    2.21 -of a repository, examine each change (comments and diffs), and view
    2.22 -the contents of each directory and file.
    2.23 -
    2.24 -Also for human consumption, the web interface provides an RSS feed of
    2.25 -the changes in a repository.  This lets you ``subscribe'' to a
    2.26 -repository using your favourite feed reader, and be automatically
    2.27 -notified of activity in that repository as soon as it happens.  I find
    2.28 -this capability much more convenient than the model of subscribing to
    2.29 -a mailing list to which notifications are sent, as it requires no
    2.30 -additional configuration on the part of whoever is serving the
    2.31 -repository.
    2.32 -
    2.33 -The web interface also lets remote users clone a repository, pull
    2.34 -changes from it, and (when the server is configured to permit it) push
    2.35 -changes back to it.  Mercurial's HTTP tunneling protocol aggressively
    2.36 -compresses data, so that it works efficiently even over low-bandwidth
    2.37 -network connections.
    2.38 -
    2.39 -The easiest way to get started with the web interface is to use your
    2.40 -web browser to visit an existing repository, such as the master
    2.41 -Mercurial repository at
    2.42 -\url{http://www.selenic.com/repo/hg?style=gitweb}.
    2.43 -
    2.44 -If you're interested in providing a web interface to your own
    2.45 -repositories, Mercurial provides two ways to do this.  The first is
    2.46 -using the \hgcmd{serve} command, which is best suited to short-term
    2.47 -``lightweight'' serving.  See section~\ref{sec:collab:serve} below for
    2.48 -details of how to use this command.  If you have a long-lived
    2.49 -repository that you'd like to make permanently available, Mercurial
    2.50 -has built-in support for the CGI (Common Gateway Interface) standard,
    2.51 -which all common web servers support.  See
    2.52 -section~\ref{sec:collab:cgi} for details of CGI configuration.
    2.53 -
    2.54 -\section{Collaboration models}
    2.55 -
    2.56 -With a suitably flexible tool, making decisions about workflow is much
    2.57 -more of a social engineering challenge than a technical one.
    2.58 -Mercurial imposes few limitations on how you can structure the flow of
    2.59 -work in a project, so it's up to you and your group to set up and live
    2.60 -with a model that matches your own particular needs.
    2.61 -
    2.62 -\subsection{Factors to keep in mind}
    2.63 -
    2.64 -The most important aspect of any model that you must keep in mind is
    2.65 -how well it matches the needs and capabilities of the people who will
    2.66 -be using it.  This might seem self-evident; even so, you still can't
    2.67 -afford to forget it for a moment.
    2.68 -
    2.69 -I once put together a workflow model that seemed to make perfect sense
    2.70 -to me, but that caused a considerable amount of consternation and
    2.71 -strife within my development team.  In spite of my attempts to explain
    2.72 -why we needed a complex set of branches, and how changes ought to flow
    2.73 -between them, a few team members revolted.  Even though they were
    2.74 -smart people, they didn't want to pay attention to the constraints we
    2.75 -were operating under, or face the consequences of those constraints in
    2.76 -the details of the model that I was advocating.
    2.77 -
    2.78 -Don't sweep foreseeable social or technical problems under the rug.
    2.79 -Whatever scheme you put into effect, you should plan for mistakes and
    2.80 -problem scenarios.  Consider adding automated machinery to prevent, or
    2.81 -quickly recover from, trouble that you can anticipate.  As an example,
    2.82 -if you intend to have a branch with not-for-release changes in it,
    2.83 -you'd do well to think early about the possibility that someone might
    2.84 -accidentally merge those changes into a release branch.  You could
    2.85 -avoid this particular problem by writing a hook that prevents changes
    2.86 -from being merged from an inappropriate branch.
    2.87 -
    2.88 -\subsection{Informal anarchy}
    2.89 -
    2.90 -I wouldn't suggest an ``anything goes'' approach as something
    2.91 -sustainable, but it's a model that's easy to grasp, and it works
    2.92 -perfectly well in a few unusual situations.
    2.93 -
    2.94 -As one example, many projects have a loose-knit group of collaborators
    2.95 -who rarely physically meet each other.  Some groups like to overcome
    2.96 -the isolation of working at a distance by organising occasional
    2.97 -``sprints''.  In a sprint, a number of people get together in a single
    2.98 -location (a company's conference room, a hotel meeting room, that kind
    2.99 -of place) and spend several days more or less locked in there, hacking
   2.100 -intensely on a handful of projects.
   2.101 -
   2.102 -A sprint is the perfect place to use the \hgcmd{serve} command, since
   2.103 -\hgcmd{serve} does not requires any fancy server infrastructure.  You
   2.104 -can get started with \hgcmd{serve} in moments, by reading
   2.105 -section~\ref{sec:collab:serve} below.  Then simply tell the person
   2.106 -next to you that you're running a server, send the URL to them in an
   2.107 -instant message, and you immediately have a quick-turnaround way to
   2.108 -work together.  They can type your URL into their web browser and
   2.109 -quickly review your changes; or they can pull a bugfix from you and
   2.110 -verify it; or they can clone a branch containing a new feature and try
   2.111 -it out.
   2.112 -
   2.113 -The charm, and the problem, with doing things in an ad hoc fashion
   2.114 -like this is that only people who know about your changes, and where
   2.115 -they are, can see them.  Such an informal approach simply doesn't
   2.116 -scale beyond a handful people, because each individual needs to know
   2.117 -about $n$ different repositories to pull from.
   2.118 -
   2.119 -\subsection{A single central repository}
   2.120 -
   2.121 -For smaller projects migrating from a centralised revision control
   2.122 -tool, perhaps the easiest way to get started is to have changes flow
   2.123 -through a single shared central repository.  This is also the
   2.124 -most common ``building block'' for more ambitious workflow schemes.
   2.125 -
   2.126 -Contributors start by cloning a copy of this repository.  They can
   2.127 -pull changes from it whenever they need to, and some (perhaps all)
   2.128 -developers have permission to push a change back when they're ready
   2.129 -for other people to see it.
   2.130 -
   2.131 -Under this model, it can still often make sense for people to pull
   2.132 -changes directly from each other, without going through the central
   2.133 -repository.  Consider a case in which I have a tentative bug fix, but
   2.134 -I am worried that if I were to publish it to the central repository,
   2.135 -it might subsequently break everyone else's trees as they pull it.  To
   2.136 -reduce the potential for damage, I can ask you to clone my repository
   2.137 -into a temporary repository of your own and test it.  This lets us put
   2.138 -off publishing the potentially unsafe change until it has had a little
   2.139 -testing.
   2.140 -
   2.141 -In this kind of scenario, people usually use the \command{ssh}
   2.142 -protocol to securely push changes to the central repository, as
   2.143 -documented in section~\ref{sec:collab:ssh}.  It's also usual to
   2.144 -publish a read-only copy of the repository over HTTP using CGI, as in
   2.145 -section~\ref{sec:collab:cgi}.  Publishing over HTTP satisfies the
   2.146 -needs of people who don't have push access, and those who want to use
   2.147 -web browsers to browse the repository's history.
   2.148 -
   2.149 -\subsection{Working with multiple branches}
   2.150 -
   2.151 -Projects of any significant size naturally tend to make progress on
   2.152 -several fronts simultaneously.  In the case of software, it's common
   2.153 -for a project to go through periodic official releases.  A release
   2.154 -might then go into ``maintenance mode'' for a while after its first
   2.155 -publication; maintenance releases tend to contain only bug fixes, not
   2.156 -new features.  In parallel with these maintenance releases, one or
   2.157 -more future releases may be under development.  People normally use
   2.158 -the word ``branch'' to refer to one of these many slightly different
   2.159 -directions in which development is proceeding.
   2.160 -
   2.161 -Mercurial is particularly well suited to managing a number of
   2.162 -simultaneous, but not identical, branches.  Each ``development
   2.163 -direction'' can live in its own central repository, and you can merge
   2.164 -changes from one to another as the need arises.  Because repositories
   2.165 -are independent of each other, unstable changes in a development
   2.166 -branch will never affect a stable branch unless someone explicitly
   2.167 -merges those changes in.
   2.168 -
   2.169 -Here's an example of how this can work in practice.  Let's say you
   2.170 -have one ``main branch'' on a central server.
   2.171 +Debido a su naturaleza descentralizada, Mercurial no impone política
   2.172 +alguna de cómo deben trabajar los grupos de personas. Sin embargo, si
   2.173 +usted es nuvo al control distribuido de versiones, es bueno tener
   2.174 +herramientas y ejemplos a la mano al pensar en posibles modelos de
   2.175 +flujo de trabajo.
   2.176 +
   2.177 +\section{La interfaz web de Mercurial}
   2.178 +
   2.179 +Mercurial tiene una poderosa interfaz web que provee bastantes
   2.180 +capacidades útiles.
   2.181 +
   2.182 +Para uso interactivo, la interfaz le permite visualizar uno o varios
   2.183 +repositorios. Puede ver la historia de un repositorio, examinar cada
   2.184 +cambio(comentarios y diferencias), y ver los contenidos de cada
   2.185 +directorio y fichero.
   2.186 +
   2.187 +Adicionalmente la interfaz provee feeds de RSS de los cambios de los
   2.188 +repositorios. Que le permite ``subscribirse''a un repositorio usando
   2.189 +su herramienta de lectura de feeds favorita, y ser notificado
   2.190 +automáticamente de la actividad en el repositorio tan pronto como
   2.191 +sucede. Me gusta mucho más este modelo que el estar suscrito a una
   2.192 +lista de correo a la cual se envían las notificaciones, dado que no
   2.193 +requiere configuración adicional de parte de quien sea que está
   2.194 +administrando el repositorio.
   2.195 +
   2.196 +La interfaz web también permite clonar repositorios a los usuarios
   2.197 +remotos, jalar cambios, y (cuando el servidor está configurado para
   2.198 +permitirlo) publicar cambios en el mismo.  El protocolo de tunneling
   2.199 +de Mercurial comprime datos agresivamente, de forma que trabaja
   2.200 +eficientemente incluso con conexiones de red con poco ancho de banda.
   2.201 +
   2.202 +La forma más sencilla de iniciarse con la interfaz web es usar su
   2.203 +navegador para visitar un repositorio existente, como por ejemplo el
   2.204 +repositorio principal de Mercurial \url{http://www.selenic.com/repo/hg?style=gitweb}.
   2.205 +
   2.206 +Si está interesado en proveer una interfaz web a sus propios
   2.207 +repositorios, Mercurial provee dos formas de hacerlo.  La primera es
   2.208 +usando la orden \hgcmd{serve}, que está enfocada a servir ``de forma
   2.209 +liviana'' y por intervalos cortos.  Para más detalles de cómo usar
   2.210 +esta orden vea la sección~\ref{sec:collab:serve} más adelante. Si
   2.211 +tiene un repositorio que desea hacer permanente, Mercurial tiene
   2.212 +soporte embebido del \command{ssh} para publicar cambios con seguridad
   2.213 +al repositorio central, como se documenta en la
   2.214 +sección~\ref{sec:collab:ssh}.  Es muy usual que se publique una copia
   2.215 +de sólo lectura en el repositorio que está corriendo sobre HTTP usando
   2.216 +CGI, como en la sección~\ref{sec:collab:cgi}.  Publicar sobre HTTP
   2.217 +satisface las necesidades de la gente que no tiene permisos de
   2.218 +publicación y de aquellos que quieren usar navegadores web para
   2.219 +visualizar la historia del repositorio.
   2.220 +
   2.221 +\subsection{Trabajo con muchas ramas}
   2.222 +
   2.223 +Los proyectos de cierta talla tienden naturlamente a progresar de
   2.224 +forma simultánea en varios frentes. En el caso del software, es común
   2.225 +que un proyecto tenga versiones periódicas oficiales. Una versión
   2.226 +puede entrar a ``modo mantenimiento'' por un tiempo después de su
   2.227 +primera publicación; las versiones de mantenimiento tienden a contener
   2.228 +solamente arreglos de fallos, pero no nuevas características. En
   2.229 +paralelo con las versiones de mantenimiento puede haber una o muchas
   2.230 +versiones futuras pueden estar en desarrollo. La gente usa normalmente
   2.231 +la palabra ``rama'' para referirse a una de las direcciones
   2.232 +ligeramente distintas en las cuales procede el desarrollo.
   2.233 +
   2.234 +Mercurial está especialmente preparado para administrar un buen número
   2.235 +de ramas simultáneas pero no idénticas. Cada ``dirección de
   2.236 +desarrollo'' puede vivir en su propio repositorio central, y puede
   2.237 +mezclar los cambios de una a otra de acuerdo con las necesidades. Dado
   2.238 +que los repositorios son independientes, uno del otro, los cambios
   2.239 +inestables de una rama de desarrollo nunca afectarán una rama estable
   2.240 +a menos que alguien explícitamente mezcle los cambios.
   2.241 +
   2.242 +A continuación un ejemplo de cómo podría hacerse esto en la
   2.243 +práctica. Digamos que tiene una ``rama principal'' en un servidor
   2.244 +central.
   2.245  \interaction{branching.init}
   2.246 -People clone it, make changes locally, test them, and push them back.
   2.247 -
   2.248 -Once the main branch reaches a release milestone, you can use the
   2.249 -\hgcmd{tag} command to give a permanent name to the milestone
   2.250 -revision.
   2.251 +Alguien lo clona, hace cambios locales, los prueba, y los publica allí
   2.252 +mismo.
   2.253 +
   2.254 +Una vez que la rama principal alcanza una estado de versión se puede
   2.255 +usar la orden \hgcmd{tag} para dar un nombre permanente a la revisión.
   2.256  \interaction{branching.tag}
   2.257 -Let's say some ongoing development occurs on the main branch.
   2.258 +Digamos que en la rama principal ocurre más desarrollo.
   2.259  \interaction{branching.main}
   2.260 -Using the tag that was recorded at the milestone, people who clone
   2.261 -that repository at any time in the future can use \hgcmd{update} to
   2.262 -get a copy of the working directory exactly as it was when that tagged
   2.263 -revision was committed.  
   2.264 +Cuando se usa la etiqueta con que se identificó la versión, la gente
   2.265 +puede clonar el repositorio en cualquier momento en el futuro
   2.266 +empleando \hgcmd{update} para obtener una copia del directorio de
   2.267 +trabajo exacta como cuando se creó la etiqueta de la revisión que se
   2.268 +consignó.
   2.269  \interaction{branching.update}
   2.270  
   2.271 -In addition, immediately after the main branch is tagged, someone can
   2.272 -then clone the main branch on the server to a new ``stable'' branch,
   2.273 -also on the server.
   2.274 +Adicionalmente, justo después de que la rama principal se etiquete,
   2.275 +alguien puede clonarla en el servidor a una nueva rama ``estable'',
   2.276 +también en el servidor.
   2.277  \interaction{branching.clone}
   2.278  
   2.279 -Someone who needs to make a change to the stable branch can then clone
   2.280 -\emph{that} repository, make their changes, commit, and push their
   2.281 -changes back there.
   2.282 +Alguien que requiera hacer un cambio en la rama estable puede clonar
   2.283 +\emph{ese} repositorio, hacer sus cambios, consignar y publicarlos
   2.284 +posteriormente al inicial.
   2.285  \interaction{branching.stable}
   2.286 -Because Mercurial repositories are independent, and Mercurial doesn't
   2.287 -move changes around automatically, the stable and main branches are
   2.288 -\emph{isolated} from each other.  The changes that you made on the
   2.289 -main branch don't ``leak'' to the stable branch, and vice versa.
   2.290 -
   2.291 -You'll often want all of your bugfixes on the stable branch to show up
   2.292 -on the main branch, too.  Rather than rewrite a bugfix on the main
   2.293 -branch, you can simply pull and merge changes from the stable to the
   2.294 -main branch, and Mercurial will bring those bugfixes in for you.
   2.295 +Puesto que los repositorios de Mercurial son independientes, y que
   2.296 +Mercurial no mueve los cambios de un lado a otro automáticamente, las
   2.297 +ramas estable y principal están \emph{aisladas} la una de la otra.
   2.298 +Los cambios que haga en la rama principal no ``se filtran'' a la rama
   2.299 +estable o vice versa.
   2.300 +
   2.301 +Es usual que los arreglos de fallos de la rama estable deban hacerse
   2.302 +aparecer en la rama principal también.  En lugar de reescribir el
   2.303 +arreglo del fallo en la rama principal, puede jalar y mezclar los
   2.304 +cambios de la rama estable a la principal, Mercurial traerá tales
   2.305 +arreglos por usted.
   2.306  \interaction{branching.merge}
   2.307 -The main branch will still contain changes that are not on the stable
   2.308 -branch, but it will also contain all of the bugfixes from the stable
   2.309 -branch.  The stable branch remains unaffected by these changes.
   2.310 +La rama principal contendtrá aún los cambios que no están en la
   2.311 +estable y contendrá además todos los arreglos de fallos de la rama
   2.312 +estable.  La rama estable permanece incólume a tales cambios.
   2.313  
   2.314  \subsection{Feature branches}
   2.315