hgbook
changeset 417:7e838acf7350
translated more paragraphs of collab to spanish
author | Igor TAmara <igor@tamarapatino.org> |
---|---|
date | Thu Nov 13 23:09:45 2008 -0500 (2008-11-13) |
parents | 15bf7d50b586 |
children | bc2136732cd6 |
files | es/Leame.1st es/collab.tex |
line diff
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}