changeset 444:6595729623f9

Instructions on contribute start daily.tex translation. Added words to Leame.1st

--- a/es/Leame.1st	Sun Oct 19 20:18:42 2008 -0500
+++ b/es/Leame.1st	Mon Oct 20 04:01:59 2008 -0500
@@ -8,13 +8,78 @@
  * Encoding UTF-8 para las tildes, eñes y demás
  * Ancho de línea de 70 caracteres
 
+= ¿Cómo contribuir? =
+Obtenga la copia :
+hg clone http://mercurial.intuxication.org/hg/mercurial_book_es/
+
+Esto le ofrecerá un clon del repositorio en el directorio recién 
+creado '''mercurial_book_es''':
+
+mercurial_book_es
+|
+|-- en
+|-- es
+|-- examples
+|-- html
+`-- sillybench
+
+El directorio de trabajo es '''es'''.
+
+
+Una vez que haya traducido o aplicado correcciones a los archivos de
+su copia local, haga un commit
+
+ hg commit -m "comentario descriptivo de lo que hizo"
+
+Siempre mantenga actualizado su repositorio local
+ hg pull
+ hg update
+
+Hay dos formas de hacer la contribución, primero envíe un correo a
[e-mail] indicando lo que desea hacer, se le puede
+otorgar permiso de escritura en el repositorio, o si lo prefiere,
+puede enviar un parche(patch).  Describimos a continuación los dos
+procedimientos : Repositorio Público y Parches.   Es preferible el
+repositorio público frente a los parches, puesto que estos segundos
+pueden tardar en propagarse más.
+
+== Repositorio Público ==
+Este sería el método preferido para que los cambios que usted haga
+automáticamente queden en el repositorio y todos los traductores
+podamos contar con la información rápidamente.
+
+Una vez que usted haya recibido la información necesaria, habiendo
+elegido su usuario y su clave podrá "publicar"(push).
+
+Como este es un sistema distribuido, después de hacer la
+consignación(commit), deberá publicarlo.
+
+ hg push
+
+Se le solicitará su usuario y clave.
+
+== Parches ==
+Este método exige que alguien reciba el parche y haga manualmente la
+aplicación del mismo, ese alguien es [e-mail] por ahora,
+después de haber hecho commit en su repositorio local, revise su log.
+
+ hg log | head
+
+Esta última orden le permitirá establecer la última revisión que se
+consignó en su repositorio local, su identificador de revisión tendrá
+el formato número:hash .   Generaría el archivo 
+/tmp/patchparahgbook.patch con la orden
+
+ hg -o /tmp/patchparahgbook.patch REV
+
+donde REV es el identificador de revisión que debió haber encontrado.
+
 = Traducción/Revisión =
 
 En esta sección indicamos quienes están traduciendo
 y quienes revisando lo traducido. Coloque su nombre 
 para que los demás colaboradores sepan en dónde 
-enfocar sus esfuerzos.  En este momento estamos dejando 
-que *make* nos guíe.
+enfocar sus esfuerzos.
 
 Indique qué archivos está traduciendo y/o revisando en 
 la lista siguiente. Cada archivo debe ser traducido y
@@ -33,6 +98,7 @@
 || branch.tex      || Igor Támara   ||    100%    || 16/10/2008 ||  19/10/2008 ||
 || preface.tex     || Javier Rojas  ||    100%    || 18/10/2008 ||  19/10/2008 ||
 || tour-basic.tex  || Javier Rojas  ||    34%     || 19/10/2008 ||             ||
+||      daily.tex  || Igor Támara   ||    19%     || 19/10/2008 ||             ||
 
 == Archivos en proceso de revisión ==
 ||'''archivo''' || '''revisor''' ||'''Estado'''||'''Inicio'''||  '''Fin'''  ||
@@ -40,7 +106,6 @@
 || branch.tex   ||               ||            ||            ||             ||
 || preface.tex  ||               ||            ||            ||             ||
 
-
 == Archivos terminados ==
 
 = Unificación de Términos de Traducción =
@@ -62,17 +127,20 @@
 
  Branch: Rama
  Bug: Fallo
+ Build Script: Guión de construcción
  Builtin: integrada/o
  Changelog: Bitácora de Cambios
  Changeset: Conjunto de Cambios
  Command: Orden
  Commit: Consignar
+ Directory: Directorio
  File: Archivo
  Head: Principal
  Hook: Gancho
  Merge: Fusión
  Milestone: Etapa
  Patch: Parche
+ Path: Ruta de archivo
  Pull: Jalar
  Push: Publicar
  Release: Versión o liberación de versión

--- a/es/daily.tex	Sun Oct 19 20:18:42 2008 -0500
+++ b/es/daily.tex	Mon Oct 20 04:01:59 2008 -0500
@@ -0,0 +1,385 @@
+\chapter{Mercurial día a día}
+\label{chap:daily}
+
+\section{Cómo indicarle a Mercurial qué archivos seguir}
+
+Mercurial no trabaja con archivos en su repositorio a menos que usted
+explícitamente se lo indique.  La orden \hgcmd{status} le mostrará
+cuáles archivos son desconocidos para Mercurial; emplea un
+``\texttt{?}'' para mostrar tales archivos.
+
+Para indicarle a Mercurial que tenga en cuenta un archivo, emplee la
+orden \hgcmd{add}. Una vez que haya adicionado el archivo, la línea
+referente al archivo al aplicar la orden \hgcmd{status} para tal
+archivo cambia de ``\texttt{?}'' a ``\texttt{A}''.
+\interaction{daily.files.add}
+
+Después de invocar \hgcmd{commit}, los archivos que haya adicionado
+antes de consignar no se listarán en la salida de \hgcmd{status}.  La
+razón para esto es que \hgcmd{status} solamente le muestra aquellos
+archivos ``interesantes''---los que usted haya modificado o a aquellos
+sobre los que usted haya indicado a Mercurial hacerles algo---de forma
+predeterminada. Si tiene un repositorio que contiene miles de
+archivos, inusualmente deseará saber cuáles de ellos están siendo
+seguidos por Mercurial, pero que no han cambiado.  (De todas maneras,
+puede obtener tal información; más adelante hablaremos de ello.)
+
+
+Cuando usted añade un archivo, Mercurial no hace nada con el inmediatamente.
+A cambio, tomará una instantánea del estado del archivo la próxima vez
+que usted consigne. Continuará haciendo seguimiento a los cambios que
+haga sobre el archivo cada vez que consigne, hasta que usted lo elimine.
+
+\subsection{Nombramiento explicíto e implícito de archivos}
+
+Mercurial tiene un comportamiento útil en el cual si a una orden,
+le pasa el nombre de un directorio, todas las órdenes lo tratarán como
+``Deseo operar en cada archivo de este directorio y sus 
+subdirectorios''.
+\interaction{daily.files.add-dir}
+Tenga en cuenta que en este ejemplo Mercurial imprimió los nombres de
+los archivos que se adicionaron, mientras que no lo hizo en el ejemplo
+anterior cuando adicionamos el archivo con nombre \filename{a}.
+
+En el último caso hicimos explícito el nombre del archivo que
+deseábamos adicionar en la línea de órdenes, y Mercurial asume en
+tales casos que usted sabe lo que está haciendo y no imprime
+información alguna.
+
+Cuando hacemos \emph{implícitos} los nombres de los archivos dando el
+nombre de un directorio, Mercurial efectua un paso extra al imprimir
+el nombre de cada archivo con el que va a hacer algo.  Esto para
+aclarar lo que está sucediendo, y reducir en lo posible una sorpresa
+silenciosa pero fatal.  Este comportamiento es común a la mayoría de
+órdenes en Mercurial.
+
+\subsection{Nota al margen:Mercurial trata archivos, no directorios}
+
+Mercurial no da seguimiento a la información de los directorios.  En
+lugar de eso tiene en cuenta las rutas de los archivos.  Antes  de
+crear un archivo, primero crea todos los directorios que hagan falta
+para completar la ruta del archivo. Después de borrar un archivo,
+borra todos los directorios vacíos que estuvieran en la ruta del
+archivo borrado. Suena como una diferencia trivial, pero tiene una
+consecuencia práctica menor: no es posible representar un directorio
+completamente vacío en Mercurial.
+
+Los directorios vacíos son inusualmente útiles, hay soluciones
+alternativas no intrusivas que puede emplear para obtener el efecto
+apropiado. Los desarrolladores de Mercurial pensaron que la
+complejidad necesaria para administrar directorios vacíos no valía la
+pena frente al beneficio limitado que esta característica podría traer.
+
+Si necesita un directorio vacío en su repositorio, hay algunas formas
+de lograrlo. Una es crear un directorio, después hacer \hgcmd{add} a
+un archivo ``escondido'' dentro de ese directorio. En sistemas tipo
+Unix, cualquier archivo cuyo nombre comience con un punto
+(``\texttt{.}'') se trata como escondido por la mayoría de
+herramientas GUI. Esta aproximación se ilustra en la figura~\ref{ex:daily:hidden}.
+
+\begin{figure}[ht]
+  \interaction{daily.files.hidden}
+  \caption{Simular un directorio vacío con un archivo escondido}
+  \label{ex:daily:hidden}
+\end{figure}
+
+Otra forma de abordar la necesidad de un archivo vacío es crear
+simplemente uno en sus guiones de construcción antes de ser necesarios.
+
+\section{How to stop tracking a file}
+
+Once you decide that a file no longer belongs in your repository, use
+the \hgcmd{remove} command; this deletes the file, and tells Mercurial
+to stop tracking it.  A removed file is represented in the output of
+\hgcmd{status} with a ``\texttt{R}''.
+\interaction{daily.files.remove}
+
+After you \hgcmd{remove} a file, Mercurial will no longer track
+changes to that file, even if you recreate a file with the same name
+in your working directory.  If you do recreate a file with the same
+name and want Mercurial to track the new file, simply \hgcmd{add} it.
+Mercurial will know that the newly added file is not related to the
+old file of the same name.
+
+\subsection{Removing a file does not affect its history}
+
+It is important to understand that removing a file has only two
+effects.
+\begin{itemize}
+\item It removes the current version of the file from the working
+  directory.
+\item It stops Mercurial from tracking changes to the file, from the
+  time of the next commit.
+\end{itemize}
+Removing a file \emph{does not} in any way alter the \emph{history} of
+the file.
+
+If you update the working directory to a changeset in which a file
+that you have removed was still tracked, it will reappear in the
+working directory, with the contents it had when you committed that
+changeset.  If you then update the working directory to a later
+changeset, in which the file had been removed, Mercurial will once
+again remove the file from the working directory.
+
+\subsection{Missing files}
+
+Mercurial considers a file that you have deleted, but not used
+\hgcmd{remove} to delete, to be \emph{missing}.  A missing file is
+represented with ``\texttt{!}'' in the output of \hgcmd{status}.
+Mercurial commands will not generally do anything with missing files.
+\interaction{daily.files.missing}
+
+If your repository contains a file that \hgcmd{status} reports as
+missing, and you want the file to stay gone, you can run
+\hgcmdargs{remove}{\hgopt{remove}{--after}} at any time later on, to
+tell Mercurial that you really did mean to remove the file.
+\interaction{daily.files.remove-after}
+
+On the other hand, if you deleted the missing file by accident, use
+\hgcmdargs{revert}{\emph{filename}} to recover the file.  It will
+reappear, in unmodified form.
+\interaction{daily.files.recover-missing}
+
+\subsection{Aside: why tell Mercurial explicitly to 
+  remove a file?}
+
+You might wonder why Mercurial requires you to explicitly tell it that
+you are deleting a file.  Early during the development of Mercurial,
+it let you delete a file however you pleased; Mercurial would notice
+the absence of the file automatically when you next ran a
+\hgcmd{commit}, and stop tracking the file.  In practice, this made it
+too easy to accidentally remove a file without noticing.
+
+\subsection{Useful shorthand---adding and removing files
+  in one step}
+
+Mercurial offers a combination command, \hgcmd{addremove}, that adds
+untracked files and marks missing files as removed.  
+\interaction{daily.files.addremove}
+The \hgcmd{commit} command also provides a \hgopt{commit}{-A} option
+that performs this same add-and-remove, immediately followed by a
+commit.
+\interaction{daily.files.commit-addremove}
+
+\section{Copying files}
+
+Mercurial provides a \hgcmd{copy} command that lets you make a new
+copy of a file.  When you copy a file using this command, Mercurial
+makes a record of the fact that the new file is a copy of the original
+file.  It treats these copied files specially when you merge your work
+with someone else's.
+
+\subsection{The results of copying during a merge}
+
+What happens during a merge is that changes ``follow'' a copy.  To
+best illustrate what this means, let's create an example.  We'll start
+with the usual tiny repository that contains a single file.
+\interaction{daily.copy.init}
+We need to do some work in parallel, so that we'll have something to
+merge.  So let's clone our repository.
+\interaction{daily.copy.clone}
+Back in our initial repository, let's use the \hgcmd{copy} command to
+make a copy of the first file we created.
+\interaction{daily.copy.copy}
+
+If we look at the output of the \hgcmd{status} command afterwards, the
+copied file looks just like a normal added file.
+\interaction{daily.copy.status}
+But if we pass the \hgopt{status}{-C} option to \hgcmd{status}, it
+prints another line of output: this is the file that our newly-added
+file was copied \emph{from}.
+\interaction{daily.copy.status-copy}
+
+Now, back in the repository we cloned, let's make a change in
+parallel.  We'll add a line of content to the original file that we
+created.
+\interaction{daily.copy.other}
+Now we have a modified \filename{file} in this repository.  When we
+pull the changes from the first repository, and merge the two heads,
+Mercurial will propagate the changes that we made locally to
+\filename{file} into its copy, \filename{new-file}.
+\interaction{daily.copy.merge}
+
+\subsection{Why should changes follow copies?}
+\label{sec:daily:why-copy}
+
+This behaviour, of changes to a file propagating out to copies of the
+file, might seem esoteric, but in most cases it's highly desirable.
+
+First of all, remember that this propagation \emph{only} happens when
+you merge.  So if you \hgcmd{copy} a file, and subsequently modify the
+original file during the normal course of your work, nothing will
+happen.
+
+The second thing to know is that modifications will only propagate
+across a copy as long as the repository that you're pulling changes
+from \emph{doesn't know} about the copy.
+
+The reason that Mercurial does this is as follows.  Let's say I make
+an important bug fix in a source file, and commit my changes.
+Meanwhile, you've decided to \hgcmd{copy} the file in your repository,
+without knowing about the bug or having seen the fix, and you have
+started hacking on your copy of the file.
+
+If you pulled and merged my changes, and Mercurial \emph{didn't}
+propagate changes across copies, your source file would now contain
+the bug, and unless you remembered to propagate the bug fix by hand,
+the bug would \emph{remain} in your copy of the file.
+
+By automatically propagating the change that fixed the bug from the
+original file to the copy, Mercurial prevents this class of problem.
+To my knowledge, Mercurial is the \emph{only} revision control system
+that propagates changes across copies like this.
+
+Once your change history has a record that the copy and subsequent
+merge occurred, there's usually no further need to propagate changes
+from the original file to the copied file, and that's why Mercurial
+only propagates changes across copies until this point, and no
+further.
+
+\subsection{How to make changes \emph{not} follow a copy}
+
+If, for some reason, you decide that this business of automatically
+propagating changes across copies is not for you, simply use your
+system's normal file copy command (on Unix-like systems, that's
+\command{cp}) to make a copy of a file, then \hgcmd{add} the new copy
+by hand.  Before you do so, though, please do reread
+section~\ref{sec:daily:why-copy}, and make an informed decision that
+this behaviour is not appropriate to your specific case.
+
+\subsection{Behaviour of the \hgcmd{copy} command}
+
+When you use the \hgcmd{copy} command, Mercurial makes a copy of each
+source file as it currently stands in the working directory.  This
+means that if you make some modifications to a file, then \hgcmd{copy}
+it without first having committed those changes, the new copy will
+also contain the modifications you have made up until that point.  (I
+find this behaviour a little counterintuitive, which is why I mention
+it here.)
+
+The \hgcmd{copy} command acts similarly to the Unix \command{cp}
+command (you can use the \hgcmd{cp} alias if you prefer).  The last
+argument is the \emph{destination}, and all prior arguments are
+\emph{sources}.  If you pass it a single file as the source, and the
+destination does not exist, it creates a new file with that name.
+\interaction{daily.copy.simple}
+If the destination is a directory, Mercurial copies its sources into
+that directory.
+\interaction{daily.copy.dir-dest}
+Copying a directory is recursive, and preserves the directory
+structure of the source.
+\interaction{daily.copy.dir-src}
+If the source and destination are both directories, the source tree is
+recreated in the destination directory.
+\interaction{daily.copy.dir-src-dest}
+
+As with the \hgcmd{rename} command, if you copy a file manually and
+then want Mercurial to know that you've copied the file, simply use
+the \hgopt{copy}{--after} option to \hgcmd{copy}.
+\interaction{daily.copy.after}
+
+\section{Renaming files}
+
+It's rather more common to need to rename a file than to make a copy
+of it.  The reason I discussed the \hgcmd{copy} command before talking
+about renaming files is that Mercurial treats a rename in essentially
+the same way as a copy.  Therefore, knowing what Mercurial does when
+you copy a file tells you what to expect when you rename a file.
+
+When you use the \hgcmd{rename} command, Mercurial makes a copy of
+each source file, then deletes it and marks the file as removed.
+\interaction{daily.rename.rename}
+The \hgcmd{status} command shows the newly copied file as added, and
+the copied-from file as removed.
+\interaction{daily.rename.status}
+As with the results of a \hgcmd{copy}, we must use the
+\hgopt{status}{-C} option to \hgcmd{status} to see that the added file
+is really being tracked by Mercurial as a copy of the original, now
+removed, file.
+\interaction{daily.rename.status-copy}
+
+As with \hgcmd{remove} and \hgcmd{copy}, you can tell Mercurial about
+a rename after the fact using the \hgopt{rename}{--after} option.  In
+most other respects, the behaviour of the \hgcmd{rename} command, and
+the options it accepts, are similar to the \hgcmd{copy} command.
+
+\subsection{Renaming files and merging changes}
+
+Since Mercurial's rename is implemented as copy-and-remove, the same
+propagation of changes happens when you merge after a rename as after
+a copy.
+
+If I modify a file, and you rename it to a new name, and then we merge
+our respective changes, my modifications to the file under its
+original name will be propagated into the file under its new name.
+(This is something you might expect to ``simply work,'' but not all
+revision control systems actually do this.)
+
+Whereas having changes follow a copy is a feature where you can
+perhaps nod and say ``yes, that might be useful,'' it should be clear
+that having them follow a rename is definitely important.  Without
+this facility, it would simply be too easy for changes to become
+orphaned when files are renamed.
+
+\subsection{Divergent renames and merging}
+
+The case of diverging names occurs when two developers start with a
+file---let's call it \filename{foo}---in their respective
+repositories.
+
+\interaction{rename.divergent.clone}
+Anne renames the file to \filename{bar}.
+\interaction{rename.divergent.rename.anne}
+Meanwhile, Bob renames it to \filename{quux}.
+\interaction{rename.divergent.rename.bob}
+
+I like to think of this as a conflict because each developer has
+expressed different intentions about what the file ought to be named.
+
+What do you think should happen when they merge their work?
+Mercurial's actual behaviour is that it always preserves \emph{both}
+names when it merges changesets that contain divergent renames.
+\interaction{rename.divergent.merge}
+
+Notice that Mercurial does warn about the divergent renames, but it
+leaves it up to you to do something about the divergence after the merge.
+
+\subsection{Convergent renames and merging}
+
+Another kind of rename conflict occurs when two people choose to
+rename different \emph{source} files to the same \emph{destination}.
+In this case, Mercurial runs its normal merge machinery, and lets you
+guide it to a suitable resolution.
+
+\subsection{Other name-related corner cases}
+
+Mercurial has a longstanding bug in which it fails to handle a merge
+where one side has a file with a given name, while another has a
+directory with the same name.  This is documented as~\bug{29}.
+\interaction{issue29.go}
+
+\section{Recovering from mistakes}
+
+Mercurial has some useful commands that will help you to recover from
+some common mistakes.
+
+The \hgcmd{revert} command lets you undo changes that you have made to
+your working directory.  For example, if you \hgcmd{add} a file by
+accident, just run \hgcmd{revert} with the name of the file you added,
+and while the file won't be touched in any way, it won't be tracked
+for adding by Mercurial any longer, either.  You can also use
+\hgcmd{revert} to get rid of erroneous changes to a file.
+
+It's useful to remember that the \hgcmd{revert} command is useful for
+changes that you have not yet committed.  Once you've committed a
+change, if you decide it was a mistake, you can still do something
+about it, though your options may be more limited.
+
+For more information about the \hgcmd{revert} command, and details
+about how to deal with changes you have already committed, see
+chapter~\ref{chap:undo}.
+
+%%% Local Variables: 
+%%% mode: latex
+%%% TeX-master: "00book"
+%%% End: