hgbook
diff es/collab.tex @ 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 | b05e35d641e4 |
children | c7234c5d01b2 |
line diff
1.1 --- a/es/collab.tex Fri Nov 07 21:42:57 2008 -0500 1.2 +++ b/es/collab.tex Mon Nov 10 23:38:36 2008 -0500 1.3 @@ -1,206 +1,120 @@ 1.4 -\chapter{Collaborating with other people} 1.5 +\chapter{Colaborar con otros} 1.6 \label{cha:collab} 1.7 1.8 -As a completely decentralised tool, Mercurial doesn't impose any 1.9 -policy on how people ought to work with each other. However, if 1.10 -you're new to distributed revision control, it helps to have some 1.11 -tools and examples in mind when you're thinking about possible 1.12 -workflow models. 1.13 - 1.14 -\section{Mercurial's web interface} 1.15 - 1.16 -Mercurial has a powerful web interface that provides several 1.17 -useful capabilities. 1.18 - 1.19 -For interactive use, the web interface lets you browse a single 1.20 -repository or a collection of repositories. You can view the history 1.21 -of a repository, examine each change (comments and diffs), and view 1.22 -the contents of each directory and file. 1.23 - 1.24 -Also for human consumption, the web interface provides an RSS feed of 1.25 -the changes in a repository. This lets you ``subscribe'' to a 1.26 -repository using your favourite feed reader, and be automatically 1.27 -notified of activity in that repository as soon as it happens. I find 1.28 -this capability much more convenient than the model of subscribing to 1.29 -a mailing list to which notifications are sent, as it requires no 1.30 -additional configuration on the part of whoever is serving the 1.31 -repository. 1.32 - 1.33 -The web interface also lets remote users clone a repository, pull 1.34 -changes from it, and (when the server is configured to permit it) push 1.35 -changes back to it. Mercurial's HTTP tunneling protocol aggressively 1.36 -compresses data, so that it works efficiently even over low-bandwidth 1.37 -network connections. 1.38 - 1.39 -The easiest way to get started with the web interface is to use your 1.40 -web browser to visit an existing repository, such as the master 1.41 -Mercurial repository at 1.42 -\url{http://www.selenic.com/repo/hg?style=gitweb}. 1.43 - 1.44 -If you're interested in providing a web interface to your own 1.45 -repositories, Mercurial provides two ways to do this. The first is 1.46 -using the \hgcmd{serve} command, which is best suited to short-term 1.47 -``lightweight'' serving. See section~\ref{sec:collab:serve} below for 1.48 -details of how to use this command. If you have a long-lived 1.49 -repository that you'd like to make permanently available, Mercurial 1.50 -has built-in support for the CGI (Common Gateway Interface) standard, 1.51 -which all common web servers support. See 1.52 -section~\ref{sec:collab:cgi} for details of CGI configuration. 1.53 - 1.54 -\section{Collaboration models} 1.55 - 1.56 -With a suitably flexible tool, making decisions about workflow is much 1.57 -more of a social engineering challenge than a technical one. 1.58 -Mercurial imposes few limitations on how you can structure the flow of 1.59 -work in a project, so it's up to you and your group to set up and live 1.60 -with a model that matches your own particular needs. 1.61 - 1.62 -\subsection{Factors to keep in mind} 1.63 - 1.64 -The most important aspect of any model that you must keep in mind is 1.65 -how well it matches the needs and capabilities of the people who will 1.66 -be using it. This might seem self-evident; even so, you still can't 1.67 -afford to forget it for a moment. 1.68 - 1.69 -I once put together a workflow model that seemed to make perfect sense 1.70 -to me, but that caused a considerable amount of consternation and 1.71 -strife within my development team. In spite of my attempts to explain 1.72 -why we needed a complex set of branches, and how changes ought to flow 1.73 -between them, a few team members revolted. Even though they were 1.74 -smart people, they didn't want to pay attention to the constraints we 1.75 -were operating under, or face the consequences of those constraints in 1.76 -the details of the model that I was advocating. 1.77 - 1.78 -Don't sweep foreseeable social or technical problems under the rug. 1.79 -Whatever scheme you put into effect, you should plan for mistakes and 1.80 -problem scenarios. Consider adding automated machinery to prevent, or 1.81 -quickly recover from, trouble that you can anticipate. As an example, 1.82 -if you intend to have a branch with not-for-release changes in it, 1.83 -you'd do well to think early about the possibility that someone might 1.84 -accidentally merge those changes into a release branch. You could 1.85 -avoid this particular problem by writing a hook that prevents changes 1.86 -from being merged from an inappropriate branch. 1.87 - 1.88 -\subsection{Informal anarchy} 1.89 - 1.90 -I wouldn't suggest an ``anything goes'' approach as something 1.91 -sustainable, but it's a model that's easy to grasp, and it works 1.92 -perfectly well in a few unusual situations. 1.93 - 1.94 -As one example, many projects have a loose-knit group of collaborators 1.95 -who rarely physically meet each other. Some groups like to overcome 1.96 -the isolation of working at a distance by organising occasional 1.97 -``sprints''. In a sprint, a number of people get together in a single 1.98 -location (a company's conference room, a hotel meeting room, that kind 1.99 -of place) and spend several days more or less locked in there, hacking 1.100 -intensely on a handful of projects. 1.101 - 1.102 -A sprint is the perfect place to use the \hgcmd{serve} command, since 1.103 -\hgcmd{serve} does not requires any fancy server infrastructure. You 1.104 -can get started with \hgcmd{serve} in moments, by reading 1.105 -section~\ref{sec:collab:serve} below. Then simply tell the person 1.106 -next to you that you're running a server, send the URL to them in an 1.107 -instant message, and you immediately have a quick-turnaround way to 1.108 -work together. They can type your URL into their web browser and 1.109 -quickly review your changes; or they can pull a bugfix from you and 1.110 -verify it; or they can clone a branch containing a new feature and try 1.111 -it out. 1.112 - 1.113 -The charm, and the problem, with doing things in an ad hoc fashion 1.114 -like this is that only people who know about your changes, and where 1.115 -they are, can see them. Such an informal approach simply doesn't 1.116 -scale beyond a handful people, because each individual needs to know 1.117 -about $n$ different repositories to pull from. 1.118 - 1.119 -\subsection{A single central repository} 1.120 - 1.121 -For smaller projects migrating from a centralised revision control 1.122 -tool, perhaps the easiest way to get started is to have changes flow 1.123 -through a single shared central repository. This is also the 1.124 -most common ``building block'' for more ambitious workflow schemes. 1.125 - 1.126 -Contributors start by cloning a copy of this repository. They can 1.127 -pull changes from it whenever they need to, and some (perhaps all) 1.128 -developers have permission to push a change back when they're ready 1.129 -for other people to see it. 1.130 - 1.131 -Under this model, it can still often make sense for people to pull 1.132 -changes directly from each other, without going through the central 1.133 -repository. Consider a case in which I have a tentative bug fix, but 1.134 -I am worried that if I were to publish it to the central repository, 1.135 -it might subsequently break everyone else's trees as they pull it. To 1.136 -reduce the potential for damage, I can ask you to clone my repository 1.137 -into a temporary repository of your own and test it. This lets us put 1.138 -off publishing the potentially unsafe change until it has had a little 1.139 -testing. 1.140 - 1.141 -In this kind of scenario, people usually use the \command{ssh} 1.142 -protocol to securely push changes to the central repository, as 1.143 -documented in section~\ref{sec:collab:ssh}. It's also usual to 1.144 -publish a read-only copy of the repository over HTTP using CGI, as in 1.145 -section~\ref{sec:collab:cgi}. Publishing over HTTP satisfies the 1.146 -needs of people who don't have push access, and those who want to use 1.147 -web browsers to browse the repository's history. 1.148 - 1.149 -\subsection{Working with multiple branches} 1.150 - 1.151 -Projects of any significant size naturally tend to make progress on 1.152 -several fronts simultaneously. In the case of software, it's common 1.153 -for a project to go through periodic official releases. A release 1.154 -might then go into ``maintenance mode'' for a while after its first 1.155 -publication; maintenance releases tend to contain only bug fixes, not 1.156 -new features. In parallel with these maintenance releases, one or 1.157 -more future releases may be under development. People normally use 1.158 -the word ``branch'' to refer to one of these many slightly different 1.159 -directions in which development is proceeding. 1.160 - 1.161 -Mercurial is particularly well suited to managing a number of 1.162 -simultaneous, but not identical, branches. Each ``development 1.163 -direction'' can live in its own central repository, and you can merge 1.164 -changes from one to another as the need arises. Because repositories 1.165 -are independent of each other, unstable changes in a development 1.166 -branch will never affect a stable branch unless someone explicitly 1.167 -merges those changes in. 1.168 - 1.169 -Here's an example of how this can work in practice. Let's say you 1.170 -have one ``main branch'' on a central server. 1.171 +Debido a su naturaleza descentralizada, Mercurial no impone política 1.172 +alguna de cómo deben trabajar los grupos de personas. Sin embargo, si 1.173 +usted es nuvo al control distribuido de versiones, es bueno tener 1.174 +herramientas y ejemplos a la mano al pensar en posibles modelos de 1.175 +flujo de trabajo. 1.176 + 1.177 +\section{La interfaz web de Mercurial} 1.178 + 1.179 +Mercurial tiene una poderosa interfaz web que provee bastantes 1.180 +capacidades útiles. 1.181 + 1.182 +Para uso interactivo, la interfaz le permite visualizar uno o varios 1.183 +repositorios. Puede ver la historia de un repositorio, examinar cada 1.184 +cambio(comentarios y diferencias), y ver los contenidos de cada 1.185 +directorio y fichero. 1.186 + 1.187 +Adicionalmente la interfaz provee feeds de RSS de los cambios de los 1.188 +repositorios. Que le permite ``subscribirse''a un repositorio usando 1.189 +su herramienta de lectura de feeds favorita, y ser notificado 1.190 +automáticamente de la actividad en el repositorio tan pronto como 1.191 +sucede. Me gusta mucho más este modelo que el estar suscrito a una 1.192 +lista de correo a la cual se envían las notificaciones, dado que no 1.193 +requiere configuración adicional de parte de quien sea que está 1.194 +administrando el repositorio. 1.195 + 1.196 +La interfaz web también permite clonar repositorios a los usuarios 1.197 +remotos, jalar cambios, y (cuando el servidor está configurado para 1.198 +permitirlo) publicar cambios en el mismo. El protocolo de tunneling 1.199 +de Mercurial comprime datos agresivamente, de forma que trabaja 1.200 +eficientemente incluso con conexiones de red con poco ancho de banda. 1.201 + 1.202 +La forma más sencilla de iniciarse con la interfaz web es usar su 1.203 +navegador para visitar un repositorio existente, como por ejemplo el 1.204 +repositorio principal de Mercurial \url{http://www.selenic.com/repo/hg?style=gitweb}. 1.205 + 1.206 +Si está interesado en proveer una interfaz web a sus propios 1.207 +repositorios, Mercurial provee dos formas de hacerlo. La primera es 1.208 +usando la orden \hgcmd{serve}, que está enfocada a servir ``de forma 1.209 +liviana'' y por intervalos cortos. Para más detalles de cómo usar 1.210 +esta orden vea la sección~\ref{sec:collab:serve} más adelante. Si 1.211 +tiene un repositorio que desea hacer permanente, Mercurial tiene 1.212 +soporte embebido del \command{ssh} para publicar cambios con seguridad 1.213 +al repositorio central, como se documenta en la 1.214 +sección~\ref{sec:collab:ssh}. Es muy usual que se publique una copia 1.215 +de sólo lectura en el repositorio que está corriendo sobre HTTP usando 1.216 +CGI, como en la sección~\ref{sec:collab:cgi}. Publicar sobre HTTP 1.217 +satisface las necesidades de la gente que no tiene permisos de 1.218 +publicación y de aquellos que quieren usar navegadores web para 1.219 +visualizar la historia del repositorio. 1.220 + 1.221 +\subsection{Trabajo con muchas ramas} 1.222 + 1.223 +Los proyectos de cierta talla tienden naturlamente a progresar de 1.224 +forma simultánea en varios frentes. En el caso del software, es común 1.225 +que un proyecto tenga versiones periódicas oficiales. Una versión 1.226 +puede entrar a ``modo mantenimiento'' por un tiempo después de su 1.227 +primera publicación; las versiones de mantenimiento tienden a contener 1.228 +solamente arreglos de fallos, pero no nuevas características. En 1.229 +paralelo con las versiones de mantenimiento puede haber una o muchas 1.230 +versiones futuras pueden estar en desarrollo. La gente usa normalmente 1.231 +la palabra ``rama'' para referirse a una de las direcciones 1.232 +ligeramente distintas en las cuales procede el desarrollo. 1.233 + 1.234 +Mercurial está especialmente preparado para administrar un buen número 1.235 +de ramas simultáneas pero no idénticas. Cada ``dirección de 1.236 +desarrollo'' puede vivir en su propio repositorio central, y puede 1.237 +mezclar los cambios de una a otra de acuerdo con las necesidades. Dado 1.238 +que los repositorios son independientes, uno del otro, los cambios 1.239 +inestables de una rama de desarrollo nunca afectarán una rama estable 1.240 +a menos que alguien explícitamente mezcle los cambios. 1.241 + 1.242 +A continuación un ejemplo de cómo podría hacerse esto en la 1.243 +práctica. Digamos que tiene una ``rama principal'' en un servidor 1.244 +central. 1.245 \interaction{branching.init} 1.246 -People clone it, make changes locally, test them, and push them back. 1.247 - 1.248 -Once the main branch reaches a release milestone, you can use the 1.249 -\hgcmd{tag} command to give a permanent name to the milestone 1.250 -revision. 1.251 +Alguien lo clona, hace cambios locales, los prueba, y los publica allí 1.252 +mismo. 1.253 + 1.254 +Una vez que la rama principal alcanza una estado de versión se puede 1.255 +usar la orden \hgcmd{tag} para dar un nombre permanente a la revisión. 1.256 \interaction{branching.tag} 1.257 -Let's say some ongoing development occurs on the main branch. 1.258 +Digamos que en la rama principal ocurre más desarrollo. 1.259 \interaction{branching.main} 1.260 -Using the tag that was recorded at the milestone, people who clone 1.261 -that repository at any time in the future can use \hgcmd{update} to 1.262 -get a copy of the working directory exactly as it was when that tagged 1.263 -revision was committed. 1.264 +Cuando se usa la etiqueta con que se identificó la versión, la gente 1.265 +puede clonar el repositorio en cualquier momento en el futuro 1.266 +empleando \hgcmd{update} para obtener una copia del directorio de 1.267 +trabajo exacta como cuando se creó la etiqueta de la revisión que se 1.268 +consignó. 1.269 \interaction{branching.update} 1.270 1.271 -In addition, immediately after the main branch is tagged, someone can 1.272 -then clone the main branch on the server to a new ``stable'' branch, 1.273 -also on the server. 1.274 +Adicionalmente, justo después de que la rama principal se etiquete, 1.275 +alguien puede clonarla en el servidor a una nueva rama ``estable'', 1.276 +también en el servidor. 1.277 \interaction{branching.clone} 1.278 1.279 -Someone who needs to make a change to the stable branch can then clone 1.280 -\emph{that} repository, make their changes, commit, and push their 1.281 -changes back there. 1.282 +Alguien que requiera hacer un cambio en la rama estable puede clonar 1.283 +\emph{ese} repositorio, hacer sus cambios, consignar y publicarlos 1.284 +posteriormente al inicial. 1.285 \interaction{branching.stable} 1.286 -Because Mercurial repositories are independent, and Mercurial doesn't 1.287 -move changes around automatically, the stable and main branches are 1.288 -\emph{isolated} from each other. The changes that you made on the 1.289 -main branch don't ``leak'' to the stable branch, and vice versa. 1.290 - 1.291 -You'll often want all of your bugfixes on the stable branch to show up 1.292 -on the main branch, too. Rather than rewrite a bugfix on the main 1.293 -branch, you can simply pull and merge changes from the stable to the 1.294 -main branch, and Mercurial will bring those bugfixes in for you. 1.295 +Puesto que los repositorios de Mercurial son independientes, y que 1.296 +Mercurial no mueve los cambios de un lado a otro automáticamente, las 1.297 +ramas estable y principal están \emph{aisladas} la una de la otra. 1.298 +Los cambios que haga en la rama principal no ``se filtran'' a la rama 1.299 +estable o vice versa. 1.300 + 1.301 +Es usual que los arreglos de fallos de la rama estable deban hacerse 1.302 +aparecer en la rama principal también. En lugar de reescribir el 1.303 +arreglo del fallo en la rama principal, puede jalar y mezclar los 1.304 +cambios de la rama estable a la principal, Mercurial traerá tales 1.305 +arreglos por usted. 1.306 \interaction{branching.merge} 1.307 -The main branch will still contain changes that are not on the stable 1.308 -branch, but it will also contain all of the bugfixes from the stable 1.309 -branch. The stable branch remains unaffected by these changes. 1.310 +La rama principal contendtrá aún los cambios que no están en la 1.311 +estable y contendrá además todos los arreglos de fallos de la rama 1.312 +estable. La rama estable permanece incólume a tales cambios. 1.313 1.314 \subsection{Feature branches} 1.315