hgbook
changeset 481:6cf30b3ed48f
translated some paragraphs
author | Javier Rojas <jerojasro@devnull.li> |
---|---|
date | Mon Jan 05 00:18:31 2009 -0500 (2009-01-05) |
parents | 4e2ebef2c9a4 |
children | 7b90444b3905 |
files | es/Leame.1st es/mq-collab.tex |
line diff
1.1 --- a/es/Leame.1st Sun Jan 04 23:04:06 2009 -0500 1.2 +++ b/es/Leame.1st Mon Jan 05 00:18:31 2009 -0500 1.3 @@ -109,7 +109,7 @@ 1.4 || mq.tex || Igor Támara || 100% || 06/12/2008 || 13/12/2008 || 1.5 || hgext.tex || Igor Támara || 100% || 13/12/2008 || 16/12/2008 || 1.6 || template.tex || Igor Támara || 100% || 27/12/2008 || 01/01/2009 || 1.7 -|| mq-collab.tex || Javier Rojas || || || || 1.8 +|| mq-collab.tex || Javier Rojas || 10% || 04/01/2009 || || 1.9 || mq-ref.tex || Javier Rojas || || || || 1.10 || cmdref.tex || Igor Támara || 100% || 01/01/2009 || 01/01/2009 || 1.11 || license.tex || Igor Támara || 100% || 16/12/2008 || 16/12/2008 || 1.12 @@ -460,6 +460,18 @@ 1.13 * "archivo". Use "fichero" en su lugar. 1.14 * "carpeta". Use "directorio". 1.15 1.16 += Diferencias de redacción = 1.17 +Hay varias expresiones que pueden terminar siendo traducidas de formas 1.18 +diferentes por los traductores, y que aún siendo ambas correctas, ponen en 1.19 +evidencia que el trabajo fue llevado a cabo por varias personas y que el estilo 1.20 +que ellas usan difiere. Una vez terminada la traducción habrá que buscar cuáles 1.21 +son éstos términos y decidirse por uno solo de ellos. A continuación se presenta 1.22 +una lista de los términos o expresiones encontrados hasta ahora 1.23 + 1.24 + * comando - orden. Ambos son la traducción para "command". Parece que la 1.25 + traducción más adecuada es "comando" 1.26 + (http://www.wordreference.com/es/translation.asp?tranword=command) 1.27 + 1.28 = Notas del traductor = 1.29 Por favor use el comando \ndt para insertar notas del traductor. Este 1.30 comando requiere un argumento. Por ejemplo: \ndt{Del inglés del original.}
2.1 --- a/es/mq-collab.tex Sun Jan 04 23:04:06 2009 -0500 2.2 +++ b/es/mq-collab.tex Mon Jan 05 00:18:31 2009 -0500 2.3 @@ -1,54 +1,61 @@ 2.4 -\chapter{Advanced uses of Mercurial Queues} 2.5 +\chapter{Usos avanzados de las Colas de Mercurial} 2.6 \label{chap:mq-collab} 2.7 2.8 -While it's easy to pick up straightforward uses of Mercurial Queues, 2.9 -use of a little discipline and some of MQ's less frequently used 2.10 -capabilities makes it possible to work in complicated development 2.11 -environments. 2.12 - 2.13 -In this chapter, I will use as an example a technique I have used to 2.14 -manage the development of an Infiniband device driver for the Linux 2.15 -kernel. The driver in question is large (at least as drivers go), 2.16 -with 25,000 lines of code spread across 35 source files. It is 2.17 -maintained by a small team of developers. 2.18 - 2.19 -While much of the material in this chapter is specific to Linux, the 2.20 -same principles apply to any code base for which you're not the 2.21 -primary owner, and upon which you need to do a lot of development. 2.22 - 2.23 -\section{The problem of many targets} 2.24 - 2.25 -The Linux kernel changes rapidly, and has never been internally 2.26 -stable; developers frequently make drastic changes between releases. 2.27 -This means that a version of the driver that works well with a 2.28 -particular released version of the kernel will not even \emph{compile} 2.29 -correctly against, typically, any other version. 2.30 - 2.31 -To maintain a driver, we have to keep a number of distinct versions of 2.32 -Linux in mind. 2.33 +Auunque es fácil aprender los usos más directos de las Colas de 2.34 +Mercurial, tener algo de disciplina junto con algunas de las 2.35 +capacidadees menos usadas de MQ hace posible trabajar en entornos de 2.36 +desarrollo complejos. 2.37 + 2.38 +En este capítulo, usaré como ejemplo una técnica que he usado para 2.39 +administrar el desarrollo de un controlador de dispositivo Infiniband 2.40 +para el kernel de Linux. El controlador en cuestión es grande 2.41 +(al menos en lo que se refiere a controladores), con 25,000 líneas de 2.42 +código esparcidas en 35 ficheros fuente. Es mantenido por un equipo 2.43 +pequeño de desarrolladores. 2.44 + 2.45 +Aunque mucho del material en este capítulo es específico de Linux, los 2.46 +mismos principios aplican a cualquier base de código de la que usted 2.47 +no sea el propietario principal, y sobre la que usted necesita hacer 2.48 +un montón de desarrollo. 2.49 + 2.50 +\section{El problema de múltiples objetivos} 2.51 + 2.52 +El kernel de Linux cambia con rapidez, y nunca ha sido estable 2.53 +internamente; los desarrolladores hacen cambios drásticos entre 2.54 +%TODO no encontré una traducción adecuada para "release". Por eso el 2.55 +%cambio 2.56 +versiones frecuentemente. Esto significa que una versión del 2.57 +controlador que funciona bien con una versión particular del kernel ni 2.58 +siquiera \emph{compilará} correctamente contra, típicamente, cualquier 2.59 +otra versión. 2.60 + 2.61 +Para mantener un controlador, debemos tener en cuenta una buena 2.62 +cantidad de versiones de Linux en mente. 2.63 \begin{itemize} 2.64 -\item One target is the main Linux kernel development tree. 2.65 - Maintenance of the code is in this case partly shared by other 2.66 - developers in the kernel community, who make ``drive-by'' 2.67 - modifications to the driver as they develop and refine kernel 2.68 - subsystems. 2.69 -\item We also maintain a number of ``backports'' to older versions of 2.70 - the Linux kernel, to support the needs of customers who are running 2.71 - older Linux distributions that do not incorporate our drivers. (To 2.72 - \emph{backport} a piece of code is to modify it to work in an older 2.73 - version of its target environment than the version it was developed 2.74 - for.) 2.75 -\item Finally, we make software releases on a schedule that is 2.76 - necessarily not aligned with those used by Linux distributors and 2.77 - kernel developers, so that we can deliver new features to customers 2.78 - without forcing them to upgrade their entire kernels or 2.79 - distributions. 2.80 +\item Un objetivo es el árbol de desarrollo principal del kernel de 2.81 + Linux. En este caso el mantenimiento del código es compartido 2.82 + parcialmente por otros desarrolladores en la comunidad del kernel, 2.83 + %TODO drive-by. 2.84 + quienes hacen modificaciones ``de-afán'' al controlador a medida que 2.85 + desarrollan y refinan subsistemas en el kernel. 2.86 + %TODO backport 2.87 +\item También mantenemos algunos ``backports'' para versiones antiguas 2.88 + del kernel de Linux, para dar soporte a las necesidades de los 2.89 + clientes que están corriendo versiones antiguas de Linux que no 2.90 + incorporan nuestros controladores. (Hacer el \emph{backport} de un 2.91 + pedazo de código es modificarlo para que trabaje en una versión 2.92 + de su entorno objetivo anterior a aquella para la cual fue escrito.) 2.93 +\item Finalmente, nosotros liberamos nuestro software de acuerdo a un 2.94 + cronograma que no necesariamente está alineado con el que usan los 2.95 + distribuidores de Linux y los desarrolladores del kernel, así que 2.96 + podemos entregar nuevas características a los clientes sin forzarlos 2.97 + a actualizar kernels completos o distribuciones. 2.98 \end{itemize} 2.99 2.100 -\subsection{Tempting approaches that don't work well} 2.101 - 2.102 -There are two ``standard'' ways to maintain a piece of software that 2.103 -has to target many different environments. 2.104 +\subsection{Aproximaciones tentadoras que no funcionan adecuadamente} 2.105 + 2.106 +Hay dos maneras estándar de mantener una porción de software que debe 2.107 +funcionar en muchos entornos diferentes. 2.108 2.109 The first is to maintain a number of branches, each intended for a 2.110 single target. The trouble with this approach is that you must