1.1 --- a/es/Leame.1st	Wed Nov 12 22:36:35 2008 -0500
     1.2 +++ b/es/Leame.1st	Thu Nov 13 23:09:45 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  ||     32%    || 03/11/2008 ||             ||
     1.6  || intro.tex	   || Igor Támara   ||	  100%	  || 08/11/2008	||  09/11/2008 ||
     1.7 -|| collab.tex      || Igor Támara   ||     10%    || 10/11/2008 ||             ||
     1.8 +|| collab.tex      || Igor Támara   ||     30%    || 10/11/2008 ||             ||
     1.9  
    1.10  == Archivos en proceso de revisión ==
    1.11  ||'''archivo'''   || '''revisor''' ||'''Estado'''||'''Inicio'''||  '''Fin'''  ||

     2.1 --- a/es/collab.tex	Wed Nov 12 22:36:35 2008 -0500
     2.2 +++ b/es/collab.tex	Thu Nov 13 23:09:45 2008 -0500
     2.3 @@ -116,192 +116,199 @@
     2.4  estable y contendrá además todos los arreglos de fallos de la rama
     2.5  estable.  La rama estable permanece incólume a tales cambios.
     2.6  
     2.7 -\subsection{Feature branches}
     2.8 -
     2.9 -For larger projects, an effective way to manage change is to break up
    2.10 -a team into smaller groups.  Each group has a shared branch of its
    2.11 -own, cloned from a single ``master'' branch used by the entire
    2.12 -project.  People working on an individual branch are typically quite
    2.13 -isolated from developments on other branches.
    2.14 +\subsection{Ramas de Características}
    2.15 +
    2.16 +En proyectos grandes, una forma efectiva de administrar los cambios es
    2.17 +dividir el equipo en grupos más pequeños. Cada grupo tiene una rama
    2.18 +compartida, clonada de una rama ``principal'' que conforma el proyecto
    2.19 +completo.   Aquellos que trabajan en ramas individuales típicamente
    2.20 +están aislados de los desarrollos de otras ramas.
    2.21  
    2.22  \begin{figure}[ht]
    2.23    \centering
    2.24    \grafix{feature-branches}
    2.25 -  \caption{Feature branches}
    2.26 +  \caption{Ramas de Características}
    2.27    \label{fig:collab:feature-branches}
    2.28  \end{figure}
    2.29  
    2.30 -When a particular feature is deemed to be in suitable shape, someone
    2.31 -on that feature team pulls and merges from the master branch into the
    2.32 -feature branch, then pushes back up to the master branch.
    2.33 -
    2.34 -\subsection{The release train}
    2.35 -
    2.36 -Some projects are organised on a ``train'' basis: a release is
    2.37 -scheduled to happen every few months, and whatever features are ready
    2.38 -when the ``train'' is ready to leave are allowed in.
    2.39 -
    2.40 -This model resembles working with feature branches.  The difference is
    2.41 -that when a feature branch misses a train, someone on the feature team
    2.42 -pulls and merges the changes that went out on that train release into
    2.43 -the feature branch, and the team continues its work on top of that
    2.44 -release so that their feature can make the next release.
    2.45 -
    2.46 -\subsection{The Linux kernel model}
    2.47 -
    2.48 -The development of the Linux kernel has a shallow hierarchical
    2.49 -structure, surrounded by a cloud of apparent chaos.  Because most
    2.50 -Linux developers use \command{git}, a distributed revision control
    2.51 -tool with capabilities similar to Mercurial, it's useful to describe
    2.52 -the way work flows in that environment; if you like the ideas, the
    2.53 -approach translates well across tools.
    2.54 -
    2.55 -At the center of the community sits Linus Torvalds, the creator of
    2.56 -Linux.  He publishes a single source repository that is considered the
    2.57 -``authoritative'' current tree by the entire developer community.
    2.58 -Anyone can clone Linus's tree, but he is very choosy about whose trees
    2.59 -he pulls from.
    2.60 -
    2.61 -Linus has a number of ``trusted lieutenants''.  As a general rule, he
    2.62 -pulls whatever changes they publish, in most cases without even
    2.63 -reviewing those changes.  Some of those lieutenants are generally
    2.64 -agreed to be ``maintainers'', responsible for specific subsystems
    2.65 -within the kernel.  If a random kernel hacker wants to make a change
    2.66 -to a subsystem that they want to end up in Linus's tree, they must
    2.67 -find out who the subsystem's maintainer is, and ask that maintainer to
    2.68 -take their change.  If the maintainer reviews their changes and agrees
    2.69 -to take them, they'll pass them along to Linus in due course.
    2.70 -
    2.71 -Individual lieutenants have their own approaches to reviewing,
    2.72 -accepting, and publishing changes; and for deciding when to feed them
    2.73 -to Linus.  In addition, there are several well known branches that
    2.74 -people use for different purposes.  For example, a few people maintain
    2.75 -``stable'' repositories of older versions of the kernel, to which they
    2.76 -apply critical fixes as needed.  Some maintainers publish multiple
    2.77 -trees: one for experimental changes; one for changes that they are
    2.78 -about to feed upstream; and so on.  Others just publish a single
    2.79 -tree.
    2.80 -
    2.81 -This model has two notable features.  The first is that it's ``pull
    2.82 -only''.  You have to ask, convince, or beg another developer to take a
    2.83 -change from you, because there are almost no trees to which more than
    2.84 -one person can push, and there's no way to push changes into a tree
    2.85 -that someone else controls.
    2.86 -
    2.87 -The second is that it's based on reputation and acclaim.  If you're an
    2.88 -unknown, Linus will probably ignore changes from you without even
    2.89 -responding.  But a subsystem maintainer will probably review them, and
    2.90 -will likely take them if they pass their criteria for suitability.
    2.91 -The more ``good'' changes you contribute to a maintainer, the more
    2.92 -likely they are to trust your judgment and accept your changes.  If
    2.93 -you're well-known and maintain a long-lived branch for something Linus
    2.94 -hasn't yet accepted, people with similar interests may pull your
    2.95 -changes regularly to keep up with your work.
    2.96 -
    2.97 -Reputation and acclaim don't necessarily cross subsystem or ``people''
    2.98 -boundaries.  If you're a respected but specialised storage hacker, and
    2.99 -you try to fix a networking bug, that change will receive a level of
   2.100 -scrutiny from a network maintainer comparable to a change from a
   2.101 -complete stranger.
   2.102 -
   2.103 -To people who come from more orderly project backgrounds, the
   2.104 -comparatively chaotic Linux kernel development process often seems
   2.105 -completely insane.  It's subject to the whims of individuals; people
   2.106 -make sweeping changes whenever they deem it appropriate; and the pace
   2.107 -of development is astounding.  And yet Linux is a highly successful,
   2.108 -well-regarded piece of software.
   2.109 -
   2.110 -\subsection{Pull-only versus shared-push collaboration}
   2.111 -
   2.112 -A perpetual source of heat in the open source community is whether a
   2.113 -development model in which people only ever pull changes from others
   2.114 -is ``better than'' one in which multiple people can push changes to a
   2.115 -shared repository.
   2.116 -
   2.117 -Typically, the backers of the shared-push model use tools that
   2.118 -actively enforce this approach.  If you're using a centralised
   2.119 -revision control tool such as Subversion, there's no way to make a
   2.120 -choice over which model you'll use: the tool gives you shared-push,
   2.121 -and if you want to do anything else, you'll have to roll your own
   2.122 -approach on top (such as applying a patch by hand).
   2.123 -
   2.124 -A good distributed revision control tool, such as Mercurial, will
   2.125 -support both models.  You and your collaborators can then structure
   2.126 -how you work together based on your own needs and preferences, not on
   2.127 -what contortions your tools force you into.
   2.128 -
   2.129 -\subsection{Where collaboration meets branch management}
   2.130 -
   2.131 -Once you and your team set up some shared repositories and start
   2.132 -propagating changes back and forth between local and shared repos, you
   2.133 -begin to face a related, but slightly different challenge: that of
   2.134 -managing the multiple directions in which your team may be moving at
   2.135 -once.  Even though this subject is intimately related to how your team
   2.136 -collaborates, it's dense enough to merit treatment of its own, in
   2.137 -chapter~\ref{chap:branch}.
   2.138 -
   2.139 -\section{The technical side of sharing}
   2.140 -
   2.141 -The remainder of this chapter is devoted to the question of serving
   2.142 -data to your collaborators.
   2.143 -
   2.144 -\section{Informal sharing with \hgcmd{serve}}
   2.145 +Cuando una rama particular alcanza un estado deseado, alguien del
   2.146 +equipo de características jala y fusiona de la rama principal hacia
   2.147 +la rama de características y publica posteriormente a la rama principal.
   2.148 +
   2.149 +\subsection{El tren de publicación}
   2.150 +
   2.151 +Algunos proyectos se organizan al estilo``tren'': Una versión se
   2.152 +planifica para ser liberada cada cierto tiempo, y las características
   2.153 +que estén listas cuando ha llegado el momento ``tren'', se incorporan.
   2.154 +
   2.155 +Este modelo tiene cierta similitud a las ramas de características. La
   2.156 +diferencia es que cuando una característica pierde el tren, alguien en
   2.157 +el equipo de características jala y fusiona los cambios que se fueron
   2.158 +en la versión liberada hacia la rama de característica, y el trabajo
   2.159 +continúa sobre lo fusionado para que la característica logre estar en
   2.160 +la próxima versión.
   2.161 +
   2.162 +\subsection{El modelo del kernel linux}
   2.163 +
   2.164 +El desarrollo del Kernel Linux tiene una estructura jerárquica
   2.165 +bastante horizontal, rodeada de una nube de caos aparente. Dado que la
   2.166 +mayoría de desarrolladores usan \command{git}, una herramienta distribuida
   2.167 +de control de versiones con capacidades similares a Mercurial, resulta
   2.168 +de utilidad describir la forma en que el trabajo fluye en tal
   2.169 +ambiente; si le gustan las ideas, la aproximación se traduce bien
   2.170 +entre Git y Mercurial.
   2.171 +
   2.172 +En el centro de la comunidad está Linus Torvalds, el creador de Linux.
   2.173 +Él publica un único repositorio que es considerado el árbol
   2.174 +``oficial'' actual por la comunidad completa de
   2.175 +desarrolladores. Cualquiera puede clonar el árbol de Linus, pero él es
   2.176 +muy selectivo acerca de los árboles de los cuales jala.
   2.177 +
   2.178 +Linux tiene varios ``lugartenientes confiables''.  Como regla, él jala
   2.179 +todos los cambios que ellos publican, en la mayoría de los casos sin
   2.180 +siquiera revisarlos.  Algunos de sus lugartenientes generalmente
   2.181 +aceptan ser los ``mantenedores'', responsables de subsistemas
   2.182 +específicos dentro del kernel.  Si un hacker cualquiera desea hacer un
   2.183 +cambio a un subsistema y busca que termine en el árbol de Linus, debe
   2.184 +encontrar quien es el mantenedor del subsistema y solicitarle que
   2.185 +tenga en cuenta su cambio.  Si el mantenedor revisa los cambios y está
   2.186 +de acuerdo en tomarlos, estos pasarán al árbol de Linus de acuerdo a
   2.187 +lo expuesto.
   2.188 +
   2.189 +Cada lugarteniente tiene su forma particular de revisar, aceptar y
   2.190 +publicar los cambios; y para decidir cuando hacerlos presentes a
   2.191 +Linus.  Adicionalmente existen varias ramas conocidas que mucha gente
   2.192 +usa para propósitos distintos. Por ejemplo, pocas personas mantienen
   2.193 +repositorios ``estables'' de versiones anteriores del kernel, a los
   2.194 +cuales aplican arreglos de fallos críticos necesarios. Algunos
   2.195 +mantenedores publican varios árboles: uno para cambios
   2.196 +experimentales; uno para cambios que van a ofrecer al mantenedor
   2.197 +principal; y así sucesivamente. Otros publican un solo árbol.
   2.198 +
   2.199 +Este modelo tiene dos características notables. La primera es que son
   2.200 +de ``jalar exclusivamente''.  Usted debe solicitar, convencer o
   2.201 +incluso rogar a otro desarrollador para que tome sus cabmios, porque
   2.202 +casi no hay árboles en los cuales más de una persona pueda publicar, y
   2.203 +no hay forma de publicar cambios en un árbol que otra persona controla.
   2.204 +
   2.205 +El segundo está basado en reputación y meritocracia.  Si usted es un
   2.206 +desconocido, Linus probablemente ignorará sus cambios, sin siquiera
   2.207 +responderle.  Pero un mantenedor de un subsistema probablemente los
   2.208 +revisara, y los acogerá en caso de que aprueben su criterio de
   2.209 +aplicabilidad.  A medida que usted ofrezca ``mejores'' cambios a un
   2.210 +mantenedor, habrá más posibilidad de que se confie en su juicio y se
   2.211 +acepten los cambios.   Si usted es reconocido y matiene una rama
   2.212 +durante bastante tiempo para algo que Linus no ha aceptado, personas
   2.213 +con intereses similares pueden jalar sus cambios regularmente para
   2.214 +estar al día con su trabajo.
   2.215 +
   2.216 +La reputación y meritocracia no necesariamente es transversal entre
   2.217 +``personas'' de diferentes subsistemas.  Si usted es respetado pero es
   2.218 +un hacker en almacenamiento y trata de arreglar un fallo de redes,
   2.219 +tal cambio puede recibir un nivel de escrutinio de un mantenedor de
   2.220 +redes comparable con el que se le haría a un completo extraño.
   2.221 +
   2.222 +Personas que vienen de proyectos con un ordenamiento distinto, sienten
   2.223 +que el proceso comparativamente caótico del Kernel Linux es
   2.224 +completamente lunático.  Es objeto de los caprichos individuales; la
   2.225 +gente desecha cambios cuando lo desean; y la fase de desarrollo es
   2.226 +alucinante. A pesar de eso Linux es una pieza de software exitosa y
   2.227 +bien reconocida.
   2.228 +
   2.229 +\subsection{Solamente jalar frente a colaboración pública}
   2.230 +
   2.231 +Una fuente perpetua de discusiones en la comunidad de código abierto
   2.232 +yace en el modelo de desarrollo en el cual la gente solamente jala
   2.233 +cambios de otros ``es mejor que'' uno  en el cual muchas personas
   2.234 +pueden publicar cambios a un repositorio compartido.
   2.235 +
   2.236 +Tícamente los partidarios del modelo de publicar usan las herramientas
   2.237 +que se apegan a este modelo.  Si usted usa una herramienta
   2.238 +centralizada de control de versiones como Subversion, no hay forma de
   2.239 +elegir qué modelo va a usar: La herramienta le ofrece publicación
   2.240 +compartida, y si desea hacer cualquier otra cosa, va a tener que
   2.241 +aplicar una aproximación artificial (tal como aplicar parches a mano).
   2.242 +
   2.243 +Una buena herramienta distribuida de control de versiones, tal como
   2.244 +Mercurial soportará los dos modelos.   Usted y sus colaboradores
   2.245 +pueden estructurar cómo trabajarán juntos basados en sus propias
   2.246 +necesidades y preferencias,  sin depender de las peripecias que la
   2.247 +herramienta les obligue a hacer.
   2.248 +
   2.249 +\subsection{Cuando la colaboración encuentra la administración ramificada}
   2.250 +
   2.251 +Una vez que usted y su equipo configurar algunos repositorios
   2.252 +compartidos y comienzan a propagar cambios entre sus repositorios
   2.253 +locales y compartidos, comenzará a encarar un reto relacionado, pero
   2.254 +un poco distinto:  Administrar las direcciones en las cuales su equipo
   2.255 +puede moverse.   A pesar de que está intimamente ligado acerca de cómo
   2.256 +interactúa su equipo, es lo suficientemente denso para ameritar un
   2.257 +tratamiento en el capítulo~\ref{chap:branch}.
   2.258 +
   2.259 +\section{Aspectos técnicos de la colaboración}
   2.260 +
   2.261 +Lo que resta del capítulo lo dedicamos a las cuestiones de servir
   2.262 +datos a sus colaboradores.
   2.263 +
   2.264 +\section{Compartir informalmente con \hgcmd{serve}}
   2.265  \label{sec:collab:serve}
   2.266  
   2.267 -Mercurial's \hgcmd{serve} command is wonderfully suited to small,
   2.268 -tight-knit, and fast-paced group environments.  It also provides a
   2.269 -great way to get a feel for using Mercurial commands over a network.
   2.270 -
   2.271 -Run \hgcmd{serve} inside a repository, and in under a second it will
   2.272 -bring up a specialised HTTP server; this will accept connections from
   2.273 -any client, and serve up data for that repository until you terminate
   2.274 -it.  Anyone who knows the URL of the server you just started, and can
   2.275 -talk to your computer over the network, can then use a web browser or
   2.276 -Mercurial to read data from that repository.  A URL for a
   2.277 -\hgcmd{serve} instance running on a laptop is likely to look something
   2.278 -like \Verb|http://my-laptop.local:8000/|.
   2.279 -
   2.280 -The \hgcmd{serve} command is \emph{not} a general-purpose web server.
   2.281 -It can do only two things:
   2.282 +La orden \hgcmd{serve} de Mercurial satisface de forma espectacular
   2.283 +las necesidades de un grupo pequeño, acoplado y de corto
   2.284 +tiempo.  Se constituye en una demostración de cómo se siente usar los
   2.285 +comandos usando la red.
   2.286 +
   2.287 +Ejecute \hgcmd{serve} dentro de un repositorio, y en pocos segundos
   2.288 +iniciará un servidor HTTP especializado; aceptará conexiones desde
   2.289 +cualquier cliente y servirá datos de este repositorio mientrs lo
   2.290 +mantenga funcionando. Todo el que sepa el URL del servidor que ha
   2.291 +iniciado, y que puede comunicarse con su computador por la red, puede
   2.292 +usar un navegador web o Mercurial para leer datos del repositorio. Un
   2.293 +URL para una instancia de \hgcmd{serve} ejecutándose en un portátil
   2.294 +debería lucir algo \Verb|http://my-laptop.local:8000/|.
   2.295 +
   2.296 +La orden \hgcmd{serve} \emph{no} es un servidor web de propósito
   2.297 +general. Solamente puede hacer dos cosas:
   2.298  \begin{itemize}
   2.299 -\item Allow people to browse the history of the repository it's
   2.300 -  serving, from their normal web browsers.
   2.301 -\item Speak Mercurial's wire protocol, so that people can
   2.302 -  \hgcmd{clone} or \hgcmd{pull} changes from that repository.
   2.303 +\item Permitir que se pueda visualizar la historia del repositorio que
   2.304 +  está sirviendo desde navegadores web.
   2.305 +\item Hablar el protocolo de conexión de Mercurial para que puedan hacer
   2.306 +  \hgcmd{clone} o \hgcmd{pull} (jalar) cambios de tal repositorio.
   2.307  \end{itemize}
   2.308 -In particular, \hgcmd{serve} won't allow remote users to \emph{modify}
   2.309 -your repository.  It's intended for read-only use.
   2.310 -
   2.311 -If you're getting started with Mercurial, there's nothing to prevent
   2.312 -you from using \hgcmd{serve} to serve up a repository on your own
   2.313 -computer, then use commands like \hgcmd{clone}, \hgcmd{incoming}, and
   2.314 -so on to talk to that server as if the repository was hosted remotely.
   2.315 -This can help you to quickly get acquainted with using commands on
   2.316 -network-hosted repositories.
   2.317 -
   2.318 -\subsection{A few things to keep in mind}
   2.319 -
   2.320 -Because it provides unauthenticated read access to all clients, you
   2.321 -should only use \hgcmd{serve} in an environment where you either don't
   2.322 -care, or have complete control over, who can access your network and
   2.323 -pull data from your repository.
   2.324 -
   2.325 -The \hgcmd{serve} command knows nothing about any firewall software
   2.326 -you might have installed on your system or network.  It cannot detect
   2.327 -or control your firewall software.  If other people are unable to talk
   2.328 -to a running \hgcmd{serve} instance, the second thing you should do
   2.329 -(\emph{after} you make sure that they're using the correct URL) is
   2.330 -check your firewall configuration.
   2.331 -
   2.332 -By default, \hgcmd{serve} listens for incoming connections on
   2.333 -port~8000.  If another process is already listening on the port you
   2.334 -want to use, you can specify a different port to listen on using the
   2.335 -\hgopt{serve}{-p} option.
   2.336 -
   2.337 -Normally, when \hgcmd{serve} starts, it prints no output, which can be
   2.338 -a bit unnerving.  If you'd like to confirm that it is indeed running
   2.339 -correctly, and find out what URL you should send to your
   2.340 -collaborators, start it with the \hggopt{-v} option.
   2.341 +En particular, \hgcmd{serve} no permitirá que los usuarios remotos
   2.342 +puedan \emph{modificar} su repositorio.  Es de tipo solo lectura.
   2.343 +
   2.344 +Si está comenzando con Mercurial, no hay nada que le impida usar
   2.345 +\hgcmd{serve} para servir un repositorio en su propio computador, y
   2.346 +usar posteriormente órdenes como \hgcmd{clone}, \hgcmd{incoming}, para
   2.347 +comunicarse con el servidor como si el repositorio estuviera alojado
   2.348 +remotamente. Lo que además puede ayudarle a adecuarse rápidamente para
   2.349 +usar comandos en repositorios alojados en la red.
   2.350 +
   2.351 +\subsection{Cuestiones adicionales para tener en cuenta}
   2.352 +
   2.353 +Dado que permite lectura sin autenticación a todos sus clientes,
   2.354 +debería usar \hgcmd{serve} exclusivamente en ambientes en los cuáles
   2.355 +no tenga problema en que otros vean, o en los cuales tenga control
   2.356 +completo acerca de quien puede acceder a su red y jalar cambios de su
   2.357 +repositorio.
   2.358 +
   2.359 +La orden \hgcmd{serve} no tiene conocimiento acerca de programas
   2.360 +cortafuegos que puedan estar instalados en su sistema o en su red. No
   2.361 +puede detectar o controlar sus cortafuegos.  Si otras personas no
   2.362 +pueden acceder a su instancia \hgcmd{serve}, lo siguiente que debería hacer
   2.363 +(\emph{después} de asegurarse que tienen el URL correcto) es verificar
   2.364 +su configuración de cortafuegos.
   2.365 +
   2.366 +De forma predeterminada, \hgcmd{serve} escucha conexiones entrantes en
   2.367 +el puerto~8000.  Si otro proceso está escuchando en tal puerto, usted
   2.368 +podrá especificar un puerto distinto para escuchar con la opción
   2.369 +\hgopt{serve}{-p} .
   2.370 +
   2.371 +Normalmente, cuando se inicia \hgcmd{serve}, no imprime nada, lo cual
   2.372 +puede ser desconcertante.  Si desea confirmar que en efecto está
   2.373 +ejecutándose correctamente, y darse cuenta qué URL debería enviar a
   2.374 +sus colaboradores, inícielo con la opción \hggopt{-v}.
   2.375  
   2.376  \section{Using the Secure Shell (ssh) protocol}
   2.377  \label{sec:collab:ssh}