hgbook
changeset 412:a9ea523446cc
Started translating collab chapter to spanish
author | Igor TAmara <igor@tamarapatino.org> |
---|---|
date | Mon Nov 10 23:38:36 2008 -0500 (2008-11-10) |
parents | 04ba1c7785ae |
children | adccb58dbe9b |
files | es/Leame.1st es/collab.tex |
line diff
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