hgbook
changeset 399:2a1067c24be1
Merging javier changes
author | Igor TAmara <igor@tamarapatino.org> |
---|---|
date | Thu Nov 06 23:07:42 2008 -0500 (2008-11-06) |
parents | c368e324eeb2 0f2170fcb79a |
children | f89ee6f63ea2 |
files | es/Leame.1st |
line diff
1.1 --- a/es/99defs.tex Thu Nov 06 23:06:16 2008 -0500 1.2 +++ b/es/99defs.tex Thu Nov 06 23:07:42 2008 -0500 1.3 @@ -122,7 +122,7 @@ 1.4 1.5 % Graphics inclusion. 1.6 \ifpdf 1.7 - \newcommand{\grafix}[1]{\includegraphics{#1}} 1.8 + \newcommand{\grafix}[2][]{\includegraphics[#1]{#2}} 1.9 \else 1.10 \newcommand{\grafix}[1]{\includegraphics{#1.png}} 1.11 \fi
2.1 --- a/es/Leame.1st Thu Nov 06 23:06:16 2008 -0500 2.2 +++ b/es/Leame.1st Thu Nov 06 23:07:42 2008 -0500 2.3 @@ -100,7 +100,8 @@ 2.4 || daily.tex || Igor Támara || 100% || 19/10/2008 || 26/10/2008 || 2.5 || tour-basic.tex || Javier Rojas || 100% || 19/10/2008 || 27/10/2008 || 2.6 || undo.tex || Igor Támara || 71% || 26/10/2008 || || 2.7 -|| tour-merge.tex || Javier Rojas || 10% || 28/10/2008 || || 2.8 +|| tour-merge.tex || Javier Rojas || 100% || 28/10/2008 || 03/11/2008 || 2.9 +|| concepts.tex || Javier Rojas || 7% || 03/11/2008 || || 2.10 2.11 == Archivos en proceso de revisión == 2.12 ||'''archivo''' || '''revisor''' ||'''Estado'''||'''Inicio'''|| '''Fin''' || 2.13 @@ -391,6 +392,10 @@ 2.14 la modificación" o algo así es una traducción demasiado literal, 2.15 así que ojo con el contexto. 2.16 2.17 +track -> seguir, monitorear 2.18 + este término suele ser usado cuando se habla de archivos, y de llevar la 2.19 + pista o monitorear los cambios en un archivo. 2.20 + 2.21 trunk -> tronco 2.22 Se refiere al nombre que recibe la línea de desarrollo 2.23 principal del repositorio que no está asociada a ninguna rama
3.1 --- a/es/concepts.tex Thu Nov 06 23:06:16 2008 -0500 3.2 +++ b/es/concepts.tex Thu Nov 06 23:07:42 2008 -0500 3.3 @@ -1,83 +1,92 @@ 3.4 -\chapter{Behind the scenes} 3.5 +\chapter{Tras bambalinas} 3.6 \label{chap:concepts} 3.7 3.8 -Unlike many revision control systems, the concepts upon which 3.9 -Mercurial is built are simple enough that it's easy to understand how 3.10 -the software really works. Knowing this certainly isn't necessary, 3.11 -but I find it useful to have a ``mental model'' of what's going on. 3.12 - 3.13 -This understanding gives me confidence that Mercurial has been 3.14 -carefully designed to be both \emph{safe} and \emph{efficient}. And 3.15 -just as importantly, if it's easy for me to retain a good idea of what 3.16 -the software is doing when I perform a revision control task, I'm less 3.17 -likely to be surprised by its behaviour. 3.18 - 3.19 -In this chapter, we'll initially cover the core concepts behind 3.20 -Mercurial's design, then continue to discuss some of the interesting 3.21 -details of its implementation. 3.22 - 3.23 -\section{Mercurial's historical record} 3.24 - 3.25 -\subsection{Tracking the history of a single file} 3.26 - 3.27 -When Mercurial tracks modifications to a file, it stores the history 3.28 -of that file in a metadata object called a \emph{filelog}. Each entry 3.29 -in the filelog contains enough information to reconstruct one revision 3.30 -of the file that is being tracked. Filelogs are stored as files in 3.31 -the \sdirname{.hg/store/data} directory. A filelog contains two kinds 3.32 -of information: revision data, and an index to help Mercurial to find 3.33 -a revision efficiently. 3.34 - 3.35 -A file that is large, or has a lot of history, has its filelog stored 3.36 -in separate data (``\texttt{.d}'' suffix) and index (``\texttt{.i}'' 3.37 -suffix) files. For small files without much history, the revision 3.38 -data and index are combined in a single ``\texttt{.i}'' file. The 3.39 -correspondence between a file in the working directory and the filelog 3.40 -that tracks its history in the repository is illustrated in 3.41 -figure~\ref{fig:concepts:filelog}. 3.42 +A diferencia de varios sistemas de control de revisiones, los 3.43 +conceptos en los que se fundamenta Mercurial son lo suficientemente 3.44 +simples como para entender fácilmente cómo funciona el software. 3.45 +Saber esto no es necesario, pero considero útil tener un ``modelo 3.46 +mental'' de qué es lo que sucede. 3.47 + 3.48 +Comprender esto me da la confianza de que Mercurial ha sido 3.49 +cuidadosamente diseñado para ser tanto \emph{seguro} como 3.50 +\emph{eficiente}. Y tal vez con la misma importancia, si es fácil 3.51 +para mí hacerme a una idea adecuada de qué está haciendo el software 3.52 +cuando llevo a cabo una tarea relacionada con control de revisiones, 3.53 +es menos probable que me sosprenda su comportamiento. 3.54 + 3.55 +En este capítulo, cubriremos inicialmente los conceptos centrales 3.56 +del diseño de Mercurial, y luego discutiremos algunos detalles 3.57 +interesantes de su implementación. 3.58 + 3.59 +\section{Registro del historial de Mercurial} 3.60 + 3.61 +\subsection{Seguir el historial de un único fichero} 3.62 + 3.63 +Cuando Mercurial sigue las modificaciones a un fichero, guarda el 3.64 +historial de dicho fichero en un objeto de metadatos llamado 3.65 +\emph{filelog}\ndt{Fichero de registro}. Cada entrada en el fichero 3.66 +de registro contiene suficiente información para reconstruir una 3.67 +revisión del fichero que se está siguiendo. Los ficheros de registro 3.68 +son almacenados como ficheros el el directorio 3.69 +\sdirname{.hg/store/data}. Un fichero de registro contiene dos tipos 3.70 +de información: datos de revisiones, y un índice para ayudar a 3.71 +Mercurial a buscar revisiones eficientemente. 3.72 + 3.73 +El fichero de registro de un fichero grande, o con un historial muy 3.74 +largo, es guardado como ficheros separados para datos (sufijo 3.75 +``\texttt{.d}'') y para el índice (sufijo ``\texttt{.i}''). Para 3.76 +ficheros pequeños con un historial pequeño, los datos de revisiones y 3.77 +el índice son combinados en un único fichero ``\texttt{.i}''. La 3.78 +correspondencia entre un fichero en el directorio de trabajo y el 3.79 +fichero de registro que hace seguimiento a su historial en el 3.80 +repositorio se ilustra en la figura~\ref{fig:concepts:filelog}. 3.81 3.82 \begin{figure}[ht] 3.83 \centering 3.84 \grafix{filelog} 3.85 - \caption{Relationships between files in working directory and 3.86 - filelogs in repository} 3.87 + \caption{Relación entre ficheros en el directorio de trabajo y 3.88 + ficheros de registro en el repositorio} 3.89 \label{fig:concepts:filelog} 3.90 \end{figure} 3.91 3.92 -\subsection{Managing tracked files} 3.93 - 3.94 -Mercurial uses a structure called a \emph{manifest} to collect 3.95 -together information about the files that it tracks. Each entry in 3.96 -the manifest contains information about the files present in a single 3.97 -changeset. An entry records which files are present in the changeset, 3.98 -the revision of each file, and a few other pieces of file metadata. 3.99 - 3.100 -\subsection{Recording changeset information} 3.101 - 3.102 -The \emph{changelog} contains information about each changeset. Each 3.103 -revision records who committed a change, the changeset comment, other 3.104 -pieces of changeset-related information, and the revision of the 3.105 -manifest to use. 3.106 - 3.107 -\subsection{Relationships between revisions} 3.108 - 3.109 -Within a changelog, a manifest, or a filelog, each revision stores a 3.110 -pointer to its immediate parent (or to its two parents, if it's a 3.111 -merge revision). As I mentioned above, there are also relationships 3.112 -between revisions \emph{across} these structures, and they are 3.113 -hierarchical in nature. 3.114 - 3.115 -For every changeset in a repository, there is exactly one revision 3.116 -stored in the changelog. Each revision of the changelog contains a 3.117 -pointer to a single revision of the manifest. A revision of the 3.118 -manifest stores a pointer to a single revision of each filelog tracked 3.119 -when that changeset was created. These relationships are illustrated 3.120 -in figure~\ref{fig:concepts:metadata}. 3.121 +\subsection{Administración de ficheros monitoreados} 3.122 + 3.123 +Mercurial usa una estructura llamada \emph{manifiesto} para 3.124 +% TODO collect together => centralizar 3.125 +centralizar la información que maneja acerca de los ficheros que 3.126 +monitorea. Cada entrada en el manifiesto contiene información acerca 3.127 +de los ficheros involucrados en un único conjunto de cambios. Una 3.128 +entrada registra qué ficheros están presentes en el conjunto de 3.129 +cambios, la revisión de cada fichero, y otros cuantos metadatos del 3.130 +mismo. 3.131 + 3.132 +\subsection{Registro de información del conjunto de cambios} 3.133 + 3.134 +La \emph{bitácora de cambios} contiene información acerca de cada 3.135 +conjunto de cambios. Cada revisión indica quién consignó un cambio, el 3.136 +comentario para el conjunto de cambios, otros datos relacionados con 3.137 +el conjunto de cambios, y la revisión del manifiesto a usar. 3.138 + 3.139 +\subsection{Relaciones entre revisiones} 3.140 + 3.141 +Dentro de una bitácora de cambios, un manifiesto, o un fichero de 3.142 +registro, cada revisión conserva un apuntador a su padre inmediato 3.143 +(o sus dos padres, si es la revisión de una fusión). Como menciońe 3.144 +anteriormente, también hay relaciones entre revisiones \emph{a través} 3.145 +de estas estructuras, y tienen naturaleza jerárquica. 3.146 + 3.147 +Por cada conjunto de cambios en un repositorio, hay exactamente una 3.148 +revisión almacenada en la bitácora de cambios. Cada revisión de la 3.149 +bitácora de cambios contiene un apuntador a una única revisión del 3.150 +manifiesto. Una revisión del manifiesto almacena un apuntador a una 3.151 +única revisión de cada fichero de registro al que se le hacía 3.152 +seguimiento cuando fue creado el conjunto de cambios. Estas relaciones 3.153 +se ilustran en la figura~\ref{fig:concepts:metadata}. 3.154 3.155 \begin{figure}[ht] 3.156 \centering 3.157 \grafix{metadata} 3.158 - \caption{Metadata relationships} 3.159 + \caption{Relaciones entre metadatos} 3.160 \label{fig:concepts:metadata} 3.161 \end{figure} 3.162
4.1 --- a/es/tour-merge.tex Thu Nov 06 23:06:16 2008 -0500 4.2 +++ b/es/tour-merge.tex Thu Nov 06 23:07:42 2008 -0500 4.3 @@ -105,185 +105,202 @@ 4.4 4.5 \subsection{Consignar los resultados de la fusión} 4.6 4.7 -Whenever we've done a merge, \hgcmd{parents} will display two parents 4.8 -until we \hgcmd{commit} the results of the merge. 4.9 +Siempre que hacemos una fusión, \hgcmd{parents} mostrará dos padres 4.10 +hasta que consignemos (\hgcmd{commit}) los resultados de la fusión. 4.11 \interaction{tour.merge.commit} 4.12 -We now have a new tip revision; notice that it has \emph{both} of 4.13 -our former heads as its parents. These are the same revisions that 4.14 -were previously displayed by \hgcmd{parents}. 4.15 +Ahora tenemos una nueva revisión de punta; note que tiene \emph{los 4.16 +dos} frentes anteriores como sus padres. Estos son las mismas 4.17 +revisiones que mostró previamente el comando \hgcmd{parents}. 4.18 \interaction{tour.merge.tip} 4.19 -In figure~\ref{fig:tour-merge:merge}, you can see a representation of 4.20 -what happens to the working directory during the merge, and how this 4.21 -affects the repository when the commit happens. During the merge, the 4.22 -working directory has two parent changesets, and these become the 4.23 -parents of the new changeset. 4.24 - 4.25 -\section{Merging conflicting changes} 4.26 - 4.27 -Most merges are simple affairs, but sometimes you'll find yourself 4.28 -merging changes where each modifies the same portions of the same 4.29 -files. Unless both modifications are identical, this results in a 4.30 -\emph{conflict}, where you have to decide how to reconcile the 4.31 -different changes into something coherent. 4.32 +En la figura~\ref{fig:tour-merge:merge} usted puede apreciar una 4.33 +representación de lo que pasa en el directorio de trabajo durante la 4.34 +fusión cuando se hace la consignación. Durante la fusión, el 4.35 +directorio de trabajo tiene dos conjuntos de cambios como sus padres, 4.36 +y éstos se vuelven los padres del nuevo conjunto de cambios. 4.37 + 4.38 +\section{Fusionar cambios con conflictos} 4.39 + 4.40 +La mayoría de las fusiones son algo simple, pero a veces usted se 4.41 +encontrará fusionando cambios donde más de uno de ellos afecta las 4.42 +mismas secciones de los mismos ficheros. A menos que ambas 4.43 +modificaciones sean idénticas, el resultado es un \emph{conflicto}, en 4.44 +donde usted debe decidir cómo reconciliar ambos cambios y producir un 4.45 +resultado coherente. 4.46 4.47 \begin{figure}[ht] 4.48 \centering 4.49 \grafix{tour-merge-conflict} 4.50 - \caption{Conflicting changes to a document} 4.51 + \caption{Cambios con conflictos a un documento} 4.52 \label{fig:tour-merge:conflict} 4.53 \end{figure} 4.54 4.55 -Figure~\ref{fig:tour-merge:conflict} illustrates an instance of two 4.56 -conflicting changes to a document. We started with a single version 4.57 -of the file; then we made some changes; while someone else made 4.58 -different changes to the same text. Our task in resolving the 4.59 -conflicting changes is to decide what the file should look like. 4.60 - 4.61 -Mercurial doesn't have a built-in facility for handling conflicts. 4.62 -Instead, it runs an external program called \command{hgmerge}. This 4.63 -is a shell script that is bundled with Mercurial; you can change it to 4.64 -behave however you please. What it does by default is try to find one 4.65 -of several different merging tools that are likely to be installed on 4.66 -your system. It first tries a few fully automatic merging tools; if 4.67 -these don't succeed (because the resolution process requires human 4.68 -guidance) or aren't present, the script tries a few different 4.69 -graphical merging tools. 4.70 - 4.71 -It's also possible to get Mercurial to run another program or script 4.72 -instead of \command{hgmerge}, by setting the \envar{HGMERGE} 4.73 -environment variable to the name of your preferred program. 4.74 - 4.75 -\subsection{Using a graphical merge tool} 4.76 - 4.77 -My preferred graphical merge tool is \command{kdiff3}, which I'll use 4.78 -to describe the features that are common to graphical file merging 4.79 -tools. You can see a screenshot of \command{kdiff3} in action in 4.80 -figure~\ref{fig:tour-merge:kdiff3}. The kind of merge it is 4.81 -performing is called a \emph{three-way merge}, because there are three 4.82 -different versions of the file of interest to us. The tool thus 4.83 -splits the upper portion of the window into three panes: 4.84 +La figura~\ref{fig:tour-merge:conflict} ilustra un ejemplo con dos 4.85 +cambios generando conflictos en un documento. Empezamos con una sola 4.86 +versión de el fichero; luego hicimos algunos cambios; mientras tanto, 4.87 +alguien más hizo cambios diferentes en el mismo texto. Lo que debemos 4.88 +hacer para resolver el conflicto causado por ambos cambios es decidir 4.89 +cómo debe quedar finalmente el fichero. 4.90 + 4.91 +Mercurial no tiene ninguna utilidad integrada para manejar conflictos. 4.92 +En vez de eso, ejecuta un programa externo llamado \command{hgmerge}. 4.93 +Es un guión de línea de comandos que es instalado junto con Mercurial; 4.94 +usted puede modificarlo para que se comporte como usted lo desee. Por 4.95 +defecto, lo que hace es tratar de encontrar una de varias herramientas 4.96 +para fusionar que es probable que estén instaladas en su sistema. 4.97 +Primero se intenta con unas herramientas para fusionar cambios 4.98 +automáticamente; si esto no tiene éxito (porque la fusión demanda 4.99 +una guía humana) o dichas herramientas no están presentes, el guión 4.100 +intenta con herramientas gráficas para fusionar. 4.101 + 4.102 +También es posible hacer que Mercurial ejecute otro programa o guión 4.103 +en vez de \command{hgmerge}, definiendo la variable de entorno 4.104 +\envar{HGMERGE} con el nombre del programa de su preferencia. 4.105 + 4.106 +\subsection{Usar una herramienta gráfica para fusión} 4.107 + 4.108 +Mi herramienta favorita para hacer fusiones es \command{kdiff3}, y la 4.109 +usaré para describir las características comunes de las herramientas 4.110 +gráficas para hacer fusiones. Puede ver una captura de pantalla de 4.111 +\command{kdiff3} ejecutándose, en la 4.112 +figura~\ref{fig:tour-merge:kdiff3}. El tipo de fusión que la 4.113 +herramienta hace se conoce como \emph{fusión de tres vías}, porque hay 4.114 +tres versiones diferentes del archivo en que estamos interesados. 4.115 +Debido a esto la herramienta divide la parte superior de la ventana en 4.116 +tres paneles. 4.117 \begin{itemize} 4.118 -\item At the left is the \emph{base} version of the file, i.e.~the 4.119 - most recent version from which the two versions we're trying to 4.120 - merge are descended. 4.121 -\item In the middle is ``our'' version of the file, with the contents 4.122 - that we modified. 4.123 -\item On the right is ``their'' version of the file, the one that 4.124 - from the changeset that we're trying to merge with. 4.125 +\item A la izquierda está la revisión \emph{base} del fichero, p.ej.~la 4.126 + versión más reciente de la que descienden las dos versiones que 4.127 + estamos tratando de fusionar. 4.128 +\item En la mitad está ``nuestra'' versión del fichero, con las 4.129 + modificaciones que hemos hecho. 4.130 +\item A la derecha está la versión del fichero de ``ellos'', la que 4.131 + forma parte del conjunto de cambios que estamos tratando de 4.132 + fusionar. 4.133 \end{itemize} 4.134 -In the pane below these is the current \emph{result} of the merge. 4.135 -Our task is to replace all of the red text, which indicates unresolved 4.136 -conflicts, with some sensible merger of the ``ours'' and ``theirs'' 4.137 -versions of the file. 4.138 - 4.139 -All four of these panes are \emph{locked together}; if we scroll 4.140 -vertically or horizontally in any of them, the others are updated to 4.141 -display the corresponding sections of their respective files. 4.142 - 4.143 -\begin{figure}[ht] 4.144 - \centering 4.145 - \grafix{kdiff3} 4.146 - \caption{Using \command{kdiff3} to merge versions of a file} 4.147 +En el panel inferior se encuentra el \emph{resultado} actual de la 4.148 +fusión. Nuestra tarea es reemplazar todo el texto rojo, que muestra 4.149 +los conflictos sin resolver, con una fusión adecuada de ``nuestra'' 4.150 +versión del fichero y la de ``ellos''. 4.151 + 4.152 +Los cuatro paneles están \emph{enlazados}; si avanzamos vertical o 4.153 +horizontalmente en cualquiera de ellos, los otros son actualizados 4.154 +para mostrar las secciones correspondientes del fichero que tengan 4.155 +asociado. 4.156 + 4.157 +\begin{figure}[ht] 4.158 + \centering 4.159 + \grafix[width=\textwidth]{kdiff3} 4.160 + \caption{Usando \command{kdiff3} para fusionar versiones de un 4.161 + fichero} 4.162 \label{fig:tour-merge:kdiff3} 4.163 \end{figure} 4.164 4.165 -For each conflicting portion of the file, we can choose to resolve 4.166 -the conflict using some combination of text from the base version, 4.167 -ours, or theirs. We can also manually edit the merged file at any 4.168 -time, in case we need to make further modifications. 4.169 - 4.170 -There are \emph{many} file merging tools available, too many to cover 4.171 -here. They vary in which platforms they are available for, and in 4.172 -their particular strengths and weaknesses. Most are tuned for merging 4.173 -files containing plain text, while a few are aimed at specialised file 4.174 -formats (generally XML). 4.175 - 4.176 -\subsection{A worked example} 4.177 - 4.178 -In this example, we will reproduce the file modification history of 4.179 -figure~\ref{fig:tour-merge:conflict} above. Let's begin by creating a 4.180 -repository with a base version of our document. 4.181 +En cada conflicto del fichero podemos escoger resolverlo usando 4.182 +cualquier combinación del texto de la revisión base, la nuestra, o la 4.183 +de ellos. También podemos editar manualmente el fichero en que queda 4.184 +la fusión, si es necesario hacer cambios adicionales. 4.185 + 4.186 +Hay \emph{muchas} herramientas para fusionar ficheros disponibles. Se 4.187 +diferencian en las plataformas para las que están disponibles, y en 4.188 +sus fortalezas y debilidades particulares. La mayoría están afinadas 4.189 +para fusionar texto plano, mientras que otras están pensadas para 4.190 +formatos de archivos especializados (generalmente XML). 4.191 + 4.192 +% TODO traduje "worked" como "real" 4.193 +\subsection{Un ejemplo real} 4.194 + 4.195 +En este ejemplo, reproduciremos el historial de modificaciones al 4.196 +fichero de la figura~\ref{fig:tour-merge:conflict} mostrada 4.197 +anteriormente. Empecemos creando un repositorio con la versión base 4.198 +de nuestro documento. 4.199 \interaction{tour-merge-conflict.wife} 4.200 -We'll clone the repository and make a change to the file. 4.201 +Clonaremos el repositorio y haremos un cambio al fichero. 4.202 \interaction{tour-merge-conflict.cousin} 4.203 -And another clone, to simulate someone else making a change to the 4.204 -file. (This hints at the idea that it's not all that unusual to merge 4.205 -with yourself when you isolate tasks in separate repositories, and 4.206 -indeed to find and resolve conflicts while doing so.) 4.207 +Y haremos otro clon, para simular a alguien más haciendo un cambio al 4.208 +mismo fichero. (Esto introduce la idea de que no es tan inusual hacer 4.209 +fusiones consigo mismo, cuando usted aísla tareas en repositorios 4.210 +separados, y de hecho encuentra conflictos al hacerlo.) 4.211 \interaction{tour-merge-conflict.son} 4.212 -Having created two different versions of the file, we'll set up an 4.213 -environment suitable for running our merge. 4.214 +Ahora que tenemos dos versiones diferentes de nuestro fichero, 4.215 +crearemos un entorno adecuado para hacer la fusión. 4.216 \interaction{tour-merge-conflict.pull} 4.217 4.218 -In this example, I won't use Mercurial's normal \command{hgmerge} 4.219 -program to do the merge, because it would drop my nice automated 4.220 -example-running tool into a graphical user interface. Instead, I'll 4.221 -set \envar{HGMERGE} to tell Mercurial to use the non-interactive 4.222 -\command{merge} command. This is bundled with many Unix-like systems. 4.223 -If you're following this example on your computer, don't bother 4.224 -setting \envar{HGMERGE}. 4.225 +En este ejemplo, no usaré el comando normal de Mercurial para hacer la 4.226 +fusión (\command{hgmerge}), porque lanzaría mi linda herramienta 4.227 +automatizada para correr ejemplos dentro de una interfaz gráfica de 4.228 +usuario. En vez de eso, definiré la variable de entorno 4.229 +\envar{HGMERGE} para indicarle a Mercurial que use el comando 4.230 +\command{merge}. Este comando forma parte de la instalación base de 4.231 +muchos sistemas Unix y similares. Si usted está ejecutando este 4.232 +ejemplo en su computador, no se moleste en definir \envar{HGMERGE}. 4.233 \interaction{tour-merge-conflict.merge} 4.234 -Because \command{merge} can't resolve the conflicting changes, it 4.235 -leaves \emph{merge markers} inside the file that has conflicts, 4.236 -indicating which lines have conflicts, and whether they came from our 4.237 -version of the file or theirs. 4.238 - 4.239 -Mercurial can tell from the way \command{merge} exits that it wasn't 4.240 -able to merge successfully, so it tells us what commands we'll need to 4.241 -run if we want to redo the merging operation. This could be useful 4.242 -if, for example, we were running a graphical merge tool and quit 4.243 -because we were confused or realised we had made a mistake. 4.244 - 4.245 -If automatic or manual merges fail, there's nothing to prevent us from 4.246 -``fixing up'' the affected files ourselves, and committing the results 4.247 -of our merge: 4.248 +Debido a que \command{merge} no puede resolver los conflictos que 4.249 +aparecen, él deja \emph{marcadores de fusión} en el fichero con 4.250 +conflictos, indicando si provienen de nuestra versión o de la de 4.251 +ellos. 4.252 + 4.253 +Mercurial puede saber ---por el código de salida del comando 4.254 +\command{merge}--- que no fue posible hacer la fusión exitosamente, 4.255 +así que nos indica qué comandos debemos ejecutar si queremos rehacer 4.256 +la fusión. Esto puede ser útil si, por ejemplo, estamos ejecutando una 4.257 +herramienta gráfica de fusión y salimos de ella porque nos confundimos 4.258 +o cometimos un error. 4.259 + 4.260 +Si la fusión ---automática o manual--- falla, no hay nada que nos 4.261 +impida ``arreglar'' los ficheros afectados por nosotros mismos, y 4.262 +consignar los resultados de nuestra fusión: 4.263 +% TODO este mercurial no tiene el comando resolve. Revisar si sigue 4.264 +% siendo necesario 4.265 \interaction{tour-merge-conflict.commit} 4.266 4.267 -\section{Simplifying the pull-merge-commit sequence} 4.268 +\section{Simplificar el ciclo jalar-fusionar-consignar} 4.269 \label{sec:tour-merge:fetch} 4.270 4.271 -The process of merging changes as outlined above is straightforward, 4.272 -but requires running three commands in sequence. 4.273 +El proceso de fusionar cambios delineado anteriomente es directo, pero 4.274 +requiere la ejecución de tres comandos en sucesión. 4.275 \begin{codesample2} 4.276 hg pull 4.277 hg merge 4.278 - hg commit -m 'Merged remote changes' 4.279 + hg commit -m 'Fusionados cambios remotos' 4.280 \end{codesample2} 4.281 -In the case of the final commit, you also need to enter a commit 4.282 -message, which is almost always going to be a piece of uninteresting 4.283 -``boilerplate'' text. 4.284 - 4.285 -It would be nice to reduce the number of steps needed, if this were 4.286 -possible. Indeed, Mercurial is distributed with an extension called 4.287 -\hgext{fetch} that does just this. 4.288 - 4.289 -Mercurial provides a flexible extension mechanism that lets people 4.290 -extend its functionality, while keeping the core of Mercurial small 4.291 -and easy to deal with. Some extensions add new commands that you can 4.292 -use from the command line, while others work ``behind the scenes,'' 4.293 -for example adding capabilities to the server. 4.294 - 4.295 -The \hgext{fetch} extension adds a new command called, not 4.296 -surprisingly, \hgcmd{fetch}. This extension acts as a combination of 4.297 -\hgcmd{pull}, \hgcmd{update} and \hgcmd{merge}. It begins by pulling 4.298 -changes from another repository into the current repository. If it 4.299 -finds that the changes added a new head to the repository, it begins a 4.300 -merge, then commits the result of the merge with an 4.301 -automatically-generated commit message. If no new heads were added, 4.302 -it updates the working directory to the new tip changeset. 4.303 - 4.304 -Enabling the \hgext{fetch} extension is easy. Edit your 4.305 -\sfilename{.hgrc}, and either go to the \rcsection{extensions} section 4.306 -or create an \rcsection{extensions} section. Then add a line that 4.307 -simply reads ``\Verb+fetch +''. 4.308 +En la consignación final usted debe proveer un mensaje adecuado, que 4.309 +casi siempre es un fragmento de texto ``de relleno'' carente de valor 4.310 +particular. 4.311 + 4.312 +Sería agradable reducir la cantidad de pasos necesarios, si fuera 4.313 +posible. De hecho, Mercurial es distribuido junto con una extensión 4.314 +llamada \hgext{fetch}\ndt{Descargar, traer.} que hace precisamente 4.315 +esto. 4.316 + 4.317 +Mercurial cuenta con un mecanismo de extensión flexible que le permite 4.318 +% TODO lets people => permite a usuarios 4.319 +a sus usuarios extender su funcionalidad, manteniendo el núcleo de 4.320 +Mercurial pequeño y fácil de manejar. Algunas extensiones añaden 4.321 +nuevos comandos que usted puede usar desde la línea de comandos, 4.322 +mientras que otros funcionan ``tras bambalinas'', por ejemplo, 4.323 +añadiendo funcionalidad al servidor. 4.324 + 4.325 +La extensión \hgext{fetch} añade un comando llamado, no 4.326 +sorpresivamente, \hgcmd{fetch}. Esta extensión actúa como una 4.327 +combinación de \hgcmd{pull}, \hgcmd{update} y \hgcmd{merge}. Empieza 4.328 +jalando cambios de otro repositorio al repositorio actual. Si 4.329 +encuentra que los cambios añaden un nuevo frente en el repositorio 4.330 +actual, inicia una fusión, y luego consigna el resultado de la misma 4.331 +con un mensaje generado automáticamente. Si no se añadieron nuevos 4.332 +frentes, actualiza el directorio de trabajo con el nuevo conjunto de 4.333 +cambios de punta. 4.334 + 4.335 +Activar la extensión \hgext{fetch} es fácil. Edite su 4.336 +\sfilename{.hgrc}, y vaya a (o cree) la sección 4.337 +\rcsection{extensions}. Luego añada una línea que diga simplemente 4.338 +``\Verb+fetch +''. 4.339 \begin{codesample2} 4.340 [extensions] 4.341 fetch = 4.342 \end{codesample2} 4.343 -(Normally, on the right-hand side of the ``\texttt{=}'' would appear 4.344 -the location of the extension, but since the \hgext{fetch} extension 4.345 -is in the standard distribution, Mercurial knows where to search for 4.346 -it.) 4.347 +(Normalmente, a la derecha del ``\texttt{=}'' debería aparecer la 4.348 +ubicación de la extensión, pero como el comando \hgext{fetch} es parte 4.349 +de la distribución estándar, Mercurial sabe dónde buscarla.) 4.350 4.351 %%% Local Variables: 4.352 %%% mode: latex