1.1 --- a/es/collab.tex	Tue Nov 11 23:14:03 2008 -0500
     1.2 +++ b/es/collab.tex	Thu Nov 13 23:09:45 2008 -0500
     1.3 @@ -116,192 +116,199 @@
     1.4  estable y contendrá además todos los arreglos de fallos de la rama
     1.5  estable.  La rama estable permanece incólume a tales cambios.
     1.6  
     1.7 -\subsection{Feature branches}
     1.8 -
     1.9 -For larger projects, an effective way to manage change is to break up
    1.10 -a team into smaller groups.  Each group has a shared branch of its
    1.11 -own, cloned from a single ``master'' branch used by the entire
    1.12 -project.  People working on an individual branch are typically quite
    1.13 -isolated from developments on other branches.
    1.14 +\subsection{Ramas de Características}
    1.15 +
    1.16 +En proyectos grandes, una forma efectiva de administrar los cambios es
    1.17 +dividir el equipo en grupos más pequeños. Cada grupo tiene una rama
    1.18 +compartida, clonada de una rama ``principal'' que conforma el proyecto
    1.19 +completo.   Aquellos que trabajan en ramas individuales típicamente
    1.20 +están aislados de los desarrollos de otras ramas.
    1.21  
    1.22  \begin{figure}[ht]
    1.23    \centering
    1.24    \grafix{feature-branches}
    1.25 -  \caption{Feature branches}
    1.26 +  \caption{Ramas de Características}
    1.27    \label{fig:collab:feature-branches}
    1.28  \end{figure}
    1.29  
    1.30 -When a particular feature is deemed to be in suitable shape, someone
    1.31 -on that feature team pulls and merges from the master branch into the
    1.32 -feature branch, then pushes back up to the master branch.
    1.33 -
    1.34 -\subsection{The release train}
    1.35 -
    1.36 -Some projects are organised on a ``train'' basis: a release is
    1.37 -scheduled to happen every few months, and whatever features are ready
    1.38 -when the ``train'' is ready to leave are allowed in.
    1.39 -
    1.40 -This model resembles working with feature branches.  The difference is
    1.41 -that when a feature branch misses a train, someone on the feature team
    1.42 -pulls and merges the changes that went out on that train release into
    1.43 -the feature branch, and the team continues its work on top of that
    1.44 -release so that their feature can make the next release.
    1.45 -
    1.46 -\subsection{The Linux kernel model}
    1.47 -
    1.48 -The development of the Linux kernel has a shallow hierarchical
    1.49 -structure, surrounded by a cloud of apparent chaos.  Because most
    1.50 -Linux developers use \command{git}, a distributed revision control
    1.51 -tool with capabilities similar to Mercurial, it's useful to describe
    1.52 -the way work flows in that environment; if you like the ideas, the
    1.53 -approach translates well across tools.
    1.54 -
    1.55 -At the center of the community sits Linus Torvalds, the creator of
    1.56 -Linux.  He publishes a single source repository that is considered the
    1.57 -``authoritative'' current tree by the entire developer community.
    1.58 -Anyone can clone Linus's tree, but he is very choosy about whose trees
    1.59 -he pulls from.
    1.60 -
    1.61 -Linus has a number of ``trusted lieutenants''.  As a general rule, he
    1.62 -pulls whatever changes they publish, in most cases without even
    1.63 -reviewing those changes.  Some of those lieutenants are generally
    1.64 -agreed to be ``maintainers'', responsible for specific subsystems
    1.65 -within the kernel.  If a random kernel hacker wants to make a change
    1.66 -to a subsystem that they want to end up in Linus's tree, they must
    1.67 -find out who the subsystem's maintainer is, and ask that maintainer to
    1.68 -take their change.  If the maintainer reviews their changes and agrees
    1.69 -to take them, they'll pass them along to Linus in due course.
    1.70 -
    1.71 -Individual lieutenants have their own approaches to reviewing,
    1.72 -accepting, and publishing changes; and for deciding when to feed them
    1.73 -to Linus.  In addition, there are several well known branches that
    1.74 -people use for different purposes.  For example, a few people maintain
    1.75 -``stable'' repositories of older versions of the kernel, to which they
    1.76 -apply critical fixes as needed.  Some maintainers publish multiple
    1.77 -trees: one for experimental changes; one for changes that they are
    1.78 -about to feed upstream; and so on.  Others just publish a single
    1.79 -tree.
    1.80 -
    1.81 -This model has two notable features.  The first is that it's ``pull
    1.82 -only''.  You have to ask, convince, or beg another developer to take a
    1.83 -change from you, because there are almost no trees to which more than
    1.84 -one person can push, and there's no way to push changes into a tree
    1.85 -that someone else controls.
    1.86 -
    1.87 -The second is that it's based on reputation and acclaim.  If you're an
    1.88 -unknown, Linus will probably ignore changes from you without even
    1.89 -responding.  But a subsystem maintainer will probably review them, and
    1.90 -will likely take them if they pass their criteria for suitability.
    1.91 -The more ``good'' changes you contribute to a maintainer, the more
    1.92 -likely they are to trust your judgment and accept your changes.  If
    1.93 -you're well-known and maintain a long-lived branch for something Linus
    1.94 -hasn't yet accepted, people with similar interests may pull your
    1.95 -changes regularly to keep up with your work.
    1.96 -
    1.97 -Reputation and acclaim don't necessarily cross subsystem or ``people''
    1.98 -boundaries.  If you're a respected but specialised storage hacker, and
    1.99 -you try to fix a networking bug, that change will receive a level of
   1.100 -scrutiny from a network maintainer comparable to a change from a
   1.101 -complete stranger.
   1.102 -
   1.103 -To people who come from more orderly project backgrounds, the
   1.104 -comparatively chaotic Linux kernel development process often seems
   1.105 -completely insane.  It's subject to the whims of individuals; people
   1.106 -make sweeping changes whenever they deem it appropriate; and the pace
   1.107 -of development is astounding.  And yet Linux is a highly successful,
   1.108 -well-regarded piece of software.
   1.109 -
   1.110 -\subsection{Pull-only versus shared-push collaboration}
   1.111 -
   1.112 -A perpetual source of heat in the open source community is whether a
   1.113 -development model in which people only ever pull changes from others
   1.114 -is ``better than'' one in which multiple people can push changes to a
   1.115 -shared repository.
   1.116 -
   1.117 -Typically, the backers of the shared-push model use tools that
   1.118 -actively enforce this approach.  If you're using a centralised
   1.119 -revision control tool such as Subversion, there's no way to make a
   1.120 -choice over which model you'll use: the tool gives you shared-push,
   1.121 -and if you want to do anything else, you'll have to roll your own
   1.122 -approach on top (such as applying a patch by hand).
   1.123 -
   1.124 -A good distributed revision control tool, such as Mercurial, will
   1.125 -support both models.  You and your collaborators can then structure
   1.126 -how you work together based on your own needs and preferences, not on
   1.127 -what contortions your tools force you into.
   1.128 -
   1.129 -\subsection{Where collaboration meets branch management}
   1.130 -
   1.131 -Once you and your team set up some shared repositories and start
   1.132 -propagating changes back and forth between local and shared repos, you
   1.133 -begin to face a related, but slightly different challenge: that of
   1.134 -managing the multiple directions in which your team may be moving at
   1.135 -once.  Even though this subject is intimately related to how your team
   1.136 -collaborates, it's dense enough to merit treatment of its own, in
   1.137 -chapter~\ref{chap:branch}.
   1.138 -
   1.139 -\section{The technical side of sharing}
   1.140 -
   1.141 -The remainder of this chapter is devoted to the question of serving
   1.142 -data to your collaborators.
   1.143 -
   1.144 -\section{Informal sharing with \hgcmd{serve}}
   1.145 +Cuando una rama particular alcanza un estado deseado, alguien del
   1.146 +equipo de características jala y fusiona de la rama principal hacia
   1.147 +la rama de características y publica posteriormente a la rama principal.
   1.148 +
   1.149 +\subsection{El tren de publicación}
   1.150 +
   1.151 +Algunos proyectos se organizan al estilo``tren'': Una versión se
   1.152 +planifica para ser liberada cada cierto tiempo, y las características
   1.153 +que estén listas cuando ha llegado el momento ``tren'', se incorporan.
   1.154 +
   1.155 +Este modelo tiene cierta similitud a las ramas de características. La
   1.156 +diferencia es que cuando una característica pierde el tren, alguien en
   1.157 +el equipo de características jala y fusiona los cambios que se fueron
   1.158 +en la versión liberada hacia la rama de característica, y el trabajo
   1.159 +continúa sobre lo fusionado para que la característica logre estar en
   1.160 +la próxima versión.
   1.161 +
   1.162 +\subsection{El modelo del kernel linux}
   1.163 +
   1.164 +El desarrollo del Kernel Linux tiene una estructura jerárquica
   1.165 +bastante horizontal, rodeada de una nube de caos aparente. Dado que la
   1.166 +mayoría de desarrolladores usan \command{git}, una herramienta distribuida
   1.167 +de control de versiones con capacidades similares a Mercurial, resulta
   1.168 +de utilidad describir la forma en que el trabajo fluye en tal
   1.169 +ambiente; si le gustan las ideas, la aproximación se traduce bien
   1.170 +entre Git y Mercurial.
   1.171 +
   1.172 +En el centro de la comunidad está Linus Torvalds, el creador de Linux.
   1.173 +Él publica un único repositorio que es considerado el árbol
   1.174 +``oficial'' actual por la comunidad completa de
   1.175 +desarrolladores. Cualquiera puede clonar el árbol de Linus, pero él es
   1.176 +muy selectivo acerca de los árboles de los cuales jala.
   1.177 +
   1.178 +Linux tiene varios ``lugartenientes confiables''.  Como regla, él jala
   1.179 +todos los cambios que ellos publican, en la mayoría de los casos sin
   1.180 +siquiera revisarlos.  Algunos de sus lugartenientes generalmente
   1.181 +aceptan ser los ``mantenedores'', responsables de subsistemas
   1.182 +específicos dentro del kernel.  Si un hacker cualquiera desea hacer un
   1.183 +cambio a un subsistema y busca que termine en el árbol de Linus, debe
   1.184 +encontrar quien es el mantenedor del subsistema y solicitarle que
   1.185 +tenga en cuenta su cambio.  Si el mantenedor revisa los cambios y está
   1.186 +de acuerdo en tomarlos, estos pasarán al árbol de Linus de acuerdo a
   1.187 +lo expuesto.
   1.188 +
   1.189 +Cada lugarteniente tiene su forma particular de revisar, aceptar y
   1.190 +publicar los cambios; y para decidir cuando hacerlos presentes a
   1.191 +Linus.  Adicionalmente existen varias ramas conocidas que mucha gente
   1.192 +usa para propósitos distintos. Por ejemplo, pocas personas mantienen
   1.193 +repositorios ``estables'' de versiones anteriores del kernel, a los
   1.194 +cuales aplican arreglos de fallos críticos necesarios. Algunos
   1.195 +mantenedores publican varios árboles: uno para cambios
   1.196 +experimentales; uno para cambios que van a ofrecer al mantenedor
   1.197 +principal; y así sucesivamente. Otros publican un solo árbol.
   1.198 +
   1.199 +Este modelo tiene dos características notables. La primera es que son
   1.200 +de ``jalar exclusivamente''.  Usted debe solicitar, convencer o
   1.201 +incluso rogar a otro desarrollador para que tome sus cabmios, porque
   1.202 +casi no hay árboles en los cuales más de una persona pueda publicar, y
   1.203 +no hay forma de publicar cambios en un árbol que otra persona controla.
   1.204 +
   1.205 +El segundo está basado en reputación y meritocracia.  Si usted es un
   1.206 +desconocido, Linus probablemente ignorará sus cambios, sin siquiera
   1.207 +responderle.  Pero un mantenedor de un subsistema probablemente los
   1.208 +revisara, y los acogerá en caso de que aprueben su criterio de
   1.209 +aplicabilidad.  A medida que usted ofrezca ``mejores'' cambios a un
   1.210 +mantenedor, habrá más posibilidad de que se confie en su juicio y se
   1.211 +acepten los cambios.   Si usted es reconocido y matiene una rama
   1.212 +durante bastante tiempo para algo que Linus no ha aceptado, personas
   1.213 +con intereses similares pueden jalar sus cambios regularmente para
   1.214 +estar al día con su trabajo.
   1.215 +
   1.216 +La reputación y meritocracia no necesariamente es transversal entre
   1.217 +``personas'' de diferentes subsistemas.  Si usted es respetado pero es
   1.218 +un hacker en almacenamiento y trata de arreglar un fallo de redes,
   1.219 +tal cambio puede recibir un nivel de escrutinio de un mantenedor de
   1.220 +redes comparable con el que se le haría a un completo extraño.
   1.221 +
   1.222 +Personas que vienen de proyectos con un ordenamiento distinto, sienten
   1.223 +que el proceso comparativamente caótico del Kernel Linux es
   1.224 +completamente lunático.  Es objeto de los caprichos individuales; la
   1.225 +gente desecha cambios cuando lo desean; y la fase de desarrollo es
   1.226 +alucinante. A pesar de eso Linux es una pieza de software exitosa y
   1.227 +bien reconocida.
   1.228 +
   1.229 +\subsection{Solamente jalar frente a colaboración pública}
   1.230 +
   1.231 +Una fuente perpetua de discusiones en la comunidad de código abierto
   1.232 +yace en el modelo de desarrollo en el cual la gente solamente jala
   1.233 +cambios de otros ``es mejor que'' uno  en el cual muchas personas
   1.234 +pueden publicar cambios a un repositorio compartido.
   1.235 +
   1.236 +Tícamente los partidarios del modelo de publicar usan las herramientas
   1.237 +que se apegan a este modelo.  Si usted usa una herramienta
   1.238 +centralizada de control de versiones como Subversion, no hay forma de
   1.239 +elegir qué modelo va a usar: La herramienta le ofrece publicación
   1.240 +compartida, y si desea hacer cualquier otra cosa, va a tener que
   1.241 +aplicar una aproximación artificial (tal como aplicar parches a mano).
   1.242 +
   1.243 +Una buena herramienta distribuida de control de versiones, tal como
   1.244 +Mercurial soportará los dos modelos.   Usted y sus colaboradores
   1.245 +pueden estructurar cómo trabajarán juntos basados en sus propias
   1.246 +necesidades y preferencias,  sin depender de las peripecias que la
   1.247 +herramienta les obligue a hacer.
   1.248 +
   1.249 +\subsection{Cuando la colaboración encuentra la administración ramificada}
   1.250 +
   1.251 +Una vez que usted y su equipo configurar algunos repositorios
   1.252 +compartidos y comienzan a propagar cambios entre sus repositorios
   1.253 +locales y compartidos, comenzará a encarar un reto relacionado, pero
   1.254 +un poco distinto:  Administrar las direcciones en las cuales su equipo
   1.255 +puede moverse.   A pesar de que está intimamente ligado acerca de cómo
   1.256 +interactúa su equipo, es lo suficientemente denso para ameritar un
   1.257 +tratamiento en el capítulo~\ref{chap:branch}.
   1.258 +
   1.259 +\section{Aspectos técnicos de la colaboración}
   1.260 +
   1.261 +Lo que resta del capítulo lo dedicamos a las cuestiones de servir
   1.262 +datos a sus colaboradores.
   1.263 +
   1.264 +\section{Compartir informalmente con \hgcmd{serve}}
   1.265  \label{sec:collab:serve}
   1.266  
   1.267 -Mercurial's \hgcmd{serve} command is wonderfully suited to small,
   1.268 -tight-knit, and fast-paced group environments.  It also provides a
   1.269 -great way to get a feel for using Mercurial commands over a network.
   1.270 -
   1.271 -Run \hgcmd{serve} inside a repository, and in under a second it will
   1.272 -bring up a specialised HTTP server; this will accept connections from
   1.273 -any client, and serve up data for that repository until you terminate
   1.274 -it.  Anyone who knows the URL of the server you just started, and can
   1.275 -talk to your computer over the network, can then use a web browser or
   1.276 -Mercurial to read data from that repository.  A URL for a
   1.277 -\hgcmd{serve} instance running on a laptop is likely to look something
   1.278 -like \Verb|http://my-laptop.local:8000/|.
   1.279 -
   1.280 -The \hgcmd{serve} command is \emph{not} a general-purpose web server.
   1.281 -It can do only two things:
   1.282 +La orden \hgcmd{serve} de Mercurial satisface de forma espectacular
   1.283 +las necesidades de un grupo pequeño, acoplado y de corto
   1.284 +tiempo.  Se constituye en una demostración de cómo se siente usar los
   1.285 +comandos usando la red.
   1.286 +
   1.287 +Ejecute \hgcmd{serve} dentro de un repositorio, y en pocos segundos
   1.288 +iniciará un servidor HTTP especializado; aceptará conexiones desde
   1.289 +cualquier cliente y servirá datos de este repositorio mientrs lo
   1.290 +mantenga funcionando. Todo el que sepa el URL del servidor que ha
   1.291 +iniciado, y que puede comunicarse con su computador por la red, puede
   1.292 +usar un navegador web o Mercurial para leer datos del repositorio. Un
   1.293 +URL para una instancia de \hgcmd{serve} ejecutándose en un portátil
   1.294 +debería lucir algo \Verb|http://my-laptop.local:8000/|.
   1.295 +
   1.296 +La orden \hgcmd{serve} \emph{no} es un servidor web de propósito
   1.297 +general. Solamente puede hacer dos cosas:
   1.298  \begin{itemize}
   1.299 -\item Allow people to browse the history of the repository it's
   1.300 -  serving, from their normal web browsers.
   1.301 -\item Speak Mercurial's wire protocol, so that people can
   1.302 -  \hgcmd{clone} or \hgcmd{pull} changes from that repository.
   1.303 +\item Permitir que se pueda visualizar la historia del repositorio que
   1.304 +  está sirviendo desde navegadores web.
   1.305 +\item Hablar el protocolo de conexión de Mercurial para que puedan hacer
   1.306 +  \hgcmd{clone} o \hgcmd{pull} (jalar) cambios de tal repositorio.
   1.307  \end{itemize}
   1.308 -In particular, \hgcmd{serve} won't allow remote users to \emph{modify}
   1.309 -your repository.  It's intended for read-only use.
   1.310 -
   1.311 -If you're getting started with Mercurial, there's nothing to prevent
   1.312 -you from using \hgcmd{serve} to serve up a repository on your own
   1.313 -computer, then use commands like \hgcmd{clone}, \hgcmd{incoming}, and
   1.314 -so on to talk to that server as if the repository was hosted remotely.
   1.315 -This can help you to quickly get acquainted with using commands on
   1.316 -network-hosted repositories.
   1.317 -
   1.318 -\subsection{A few things to keep in mind}
   1.319 -
   1.320 -Because it provides unauthenticated read access to all clients, you
   1.321 -should only use \hgcmd{serve} in an environment where you either don't
   1.322 -care, or have complete control over, who can access your network and
   1.323 -pull data from your repository.
   1.324 -
   1.325 -The \hgcmd{serve} command knows nothing about any firewall software
   1.326 -you might have installed on your system or network.  It cannot detect
   1.327 -or control your firewall software.  If other people are unable to talk
   1.328 -to a running \hgcmd{serve} instance, the second thing you should do
   1.329 -(\emph{after} you make sure that they're using the correct URL) is
   1.330 -check your firewall configuration.
   1.331 -
   1.332 -By default, \hgcmd{serve} listens for incoming connections on
   1.333 -port~8000.  If another process is already listening on the port you
   1.334 -want to use, you can specify a different port to listen on using the
   1.335 -\hgopt{serve}{-p} option.
   1.336 -
   1.337 -Normally, when \hgcmd{serve} starts, it prints no output, which can be
   1.338 -a bit unnerving.  If you'd like to confirm that it is indeed running
   1.339 -correctly, and find out what URL you should send to your
   1.340 -collaborators, start it with the \hggopt{-v} option.
   1.341 +En particular, \hgcmd{serve} no permitirá que los usuarios remotos
   1.342 +puedan \emph{modificar} su repositorio.  Es de tipo solo lectura.
   1.343 +
   1.344 +Si está comenzando con Mercurial, no hay nada que le impida usar
   1.345 +\hgcmd{serve} para servir un repositorio en su propio computador, y
   1.346 +usar posteriormente órdenes como \hgcmd{clone}, \hgcmd{incoming}, para
   1.347 +comunicarse con el servidor como si el repositorio estuviera alojado
   1.348 +remotamente. Lo que además puede ayudarle a adecuarse rápidamente para
   1.349 +usar comandos en repositorios alojados en la red.
   1.350 +
   1.351 +\subsection{Cuestiones adicionales para tener en cuenta}
   1.352 +
   1.353 +Dado que permite lectura sin autenticación a todos sus clientes,
   1.354 +debería usar \hgcmd{serve} exclusivamente en ambientes en los cuáles
   1.355 +no tenga problema en que otros vean, o en los cuales tenga control
   1.356 +completo acerca de quien puede acceder a su red y jalar cambios de su
   1.357 +repositorio.
   1.358 +
   1.359 +La orden \hgcmd{serve} no tiene conocimiento acerca de programas
   1.360 +cortafuegos que puedan estar instalados en su sistema o en su red. No
   1.361 +puede detectar o controlar sus cortafuegos.  Si otras personas no
   1.362 +pueden acceder a su instancia \hgcmd{serve}, lo siguiente que debería hacer
   1.363 +(\emph{después} de asegurarse que tienen el URL correcto) es verificar
   1.364 +su configuración de cortafuegos.
   1.365 +
   1.366 +De forma predeterminada, \hgcmd{serve} escucha conexiones entrantes en
   1.367 +el puerto~8000.  Si otro proceso está escuchando en tal puerto, usted
   1.368 +podrá especificar un puerto distinto para escuchar con la opción
   1.369 +\hgopt{serve}{-p} .
   1.370 +
   1.371 +Normalmente, cuando se inicia \hgcmd{serve}, no imprime nada, lo cual
   1.372 +puede ser desconcertante.  Si desea confirmar que en efecto está
   1.373 +ejecutándose correctamente, y darse cuenta qué URL debería enviar a
   1.374 +sus colaboradores, inícielo con la opción \hggopt{-v}.
   1.375  
   1.376  \section{Using the Secure Shell (ssh) protocol}
   1.377  \label{sec:collab:ssh}