1.1 --- a/en/99defs.tex	Thu Jan 15 10:13:51 2009 +0100
     1.2 +++ b/en/99defs.tex	Thu Jan 29 22:00:07 2009 -0800
     1.3 @@ -136,6 +136,10 @@
     1.4  % Reference entry for a command option with only long form.
     1.5  \newcommand{\loptref}[2]{\subsubsection{\hgopt{#1}{--#2} option}}
     1.6  
     1.7 +% command to generate a footnote to be used as a translator's note
     1.8 +\newcommand{\ndt}[1]{\footnote{\textbf{N. del T.} #1}}
     1.9 +
    1.10 +
    1.11  %%% Local Variables: 
    1.12  %%% mode: latex
    1.13  %%% TeX-master: "00book"

     2.1 --- a/en/collab.tex	Thu Jan 15 10:13:51 2009 +0100
     2.2 +++ b/en/collab.tex	Thu Jan 29 22:00:07 2009 -0800
     2.3 @@ -461,7 +461,7 @@
     2.4  take a look at your system documentation to figure out how to install
     2.5  it.
     2.6  
     2.7 -On Windows, you'll first need to choose download a suitable ssh
     2.8 +On Windows, you'll first need to download a suitable ssh
     2.9  client.  There are two alternatives.
    2.10  \begin{itemize}
    2.11  \item Simon Tatham's excellent PuTTY package~\cite{web:putty} provides
    2.12 @@ -495,7 +495,7 @@
    2.13  
    2.14  When you generate a key pair, it's usually \emph{highly} advisable to
    2.15  protect it with a passphrase.  (The only time that you might not want
    2.16 -to do this id when you're using the ssh protocol for automated tasks
    2.17 +to do this is when you're using the ssh protocol for automated tasks
    2.18  on a secure network.)
    2.19  
    2.20  Simply generating a key pair isn't enough, however.  You'll need to
    2.21 @@ -737,7 +737,7 @@
    2.22  named something like \dirname{public\_html} in their home directory,
    2.23  from which they can serve up web pages.  A file named \filename{foo}
    2.24  in this directory will be accessible at a URL of the form
    2.25 -\texttt{http://www.example.com/\~username/foo}.
    2.26 +\texttt{http://www.example.com/\~{}username/foo}.
    2.27  
    2.28  To get started, find the \sfilename{hgweb.cgi} script that should be
    2.29  present in your Mercurial installation.  If you can't quickly find a

     3.1 --- a/en/concepts.tex	Thu Jan 15 10:13:51 2009 +0100
     3.2 +++ b/en/concepts.tex	Thu Jan 29 22:00:07 2009 -0800
     3.3 @@ -309,7 +309,7 @@
     3.4  changesets to see which one introduced a bug.  In cases like this, the
     3.5  natural thing to do is update the working directory to the changeset
     3.6  you're interested in, and then examine the files in the working
     3.7 -directory directly to see their contents as they werea when you
     3.8 +directory directly to see their contents as they were when you
     3.9  committed that changeset.  The effect of this is shown in
    3.10  figure~\ref{fig:concepts:wdir-pre-branch}.
    3.11  

     4.1 --- a/en/examples/bisect	Thu Jan 15 10:13:51 2009 +0100
     4.2 +++ b/en/examples/bisect	Thu Jan 29 22:00:07 2009 -0800
     4.3 @@ -1,7 +1,11 @@
     4.4  #!/bin/bash
     4.5  
     4.6 +if  hg -v | head -1 | grep -e "version 0.*"
     4.7 +then
     4.8 +#On mercurial 1.0 and later bisect is a builtin
     4.9  echo '[extensions]' >> $HGRC
    4.10  echo 'hbisect =' >> $HGRC
    4.11 +fi
    4.12  
    4.13  # XXX There's some kind of horrible nondeterminism in the execution of
    4.14  # bisect at the moment.  Ugh.

     5.1 --- a/en/examples/bisect.commits.out	Thu Jan 15 10:13:51 2009 +0100
     5.2 +++ b/en/examples/bisect.commits.out	Thu Jan 29 22:00:07 2009 -0800
     5.3 @@ -8,38 +8,3 @@
     5.4  
     5.5  
     5.6  
     5.7 -
     5.8 -
     5.9 -
    5.10 -
    5.11 -
    5.12 -
    5.13 -
    5.14 -
    5.15 -
    5.16 -
    5.17 -
    5.18 -
    5.19 -
    5.20 -
    5.21 -
    5.22 -
    5.23 -
    5.24 -
    5.25 -
    5.26 -
    5.27 -
    5.28 -
    5.29 -
    5.30 -
    5.31 -
    5.32 -
    5.33 -
    5.34 -
    5.35 -
    5.36 -
    5.37 -
    5.38 -
    5.39 -
    5.40 -
    5.41 -

     6.1 --- a/en/examples/bisect.help.out	Thu Jan 15 10:13:51 2009 +0100
     6.2 +++ b/en/examples/bisect.help.out	Thu Jan 29 22:00:07 2009 -0800
     6.3 @@ -19,3 +19,5 @@
     6.4  
     6.5  
     6.6  
     6.7 +
     6.8 +

     7.1 --- a/en/examples/bisect.init.out	Thu Jan 15 10:13:51 2009 +0100
     7.2 +++ b/en/examples/bisect.init.out	Thu Jan 29 22:00:07 2009 -0800
     7.3 @@ -1,3 +1,2 @@
     7.4  
     7.5  
     7.6 -

     8.1 --- a/en/examples/bisect.search.bad-init.out	Thu Jan 15 10:13:51 2009 +0100
     8.2 +++ b/en/examples/bisect.search.bad-init.out	Thu Jan 29 22:00:07 2009 -0800
     8.3 @@ -1,22 +1,1 @@
     8.4  
     8.5 -
     8.6 -
     8.7 -
     8.8 -
     8.9 -
    8.10 -
    8.11 -
    8.12 -
    8.13 -
    8.14 -
    8.15 -
    8.16 -
    8.17 -
    8.18 -
    8.19 -
    8.20 -
    8.21 -
    8.22 -
    8.23 -
    8.24 -
    8.25 -

     9.1 --- a/en/examples/bisect.search.good-init.out	Thu Jan 15 10:13:51 2009 +0100
     9.2 +++ b/en/examples/bisect.search.good-init.out	Thu Jan 29 22:00:07 2009 -0800
     9.3 @@ -1,22 +1,3 @@
     9.4  
     9.5  
     9.6  
     9.7 -
     9.8 -
     9.9 -
    9.10 -
    9.11 -
    9.12 -
    9.13 -
    9.14 -
    9.15 -
    9.16 -
    9.17 -
    9.18 -
    9.19 -
    9.20 -
    9.21 -
    9.22 -
    9.23 -
    9.24 -
    9.25 -

    10.1 --- a/en/examples/bisect.search.init.out	Thu Jan 15 10:13:51 2009 +0100
    10.2 +++ b/en/examples/bisect.search.init.out	Thu Jan 29 22:00:07 2009 -0800
    10.3 @@ -3,20 +3,3 @@
    10.4  
    10.5  
    10.6  
    10.7 -
    10.8 -
    10.9 -
   10.10 -
   10.11 -
   10.12 -
   10.13 -
   10.14 -
   10.15 -
   10.16 -
   10.17 -
   10.18 -
   10.19 -
   10.20 -
   10.21 -
   10.22 -
   10.23 -

    11.1 --- a/en/examples/bisect.search.reset.out	Thu Jan 15 10:13:51 2009 +0100
    11.2 +++ b/en/examples/bisect.search.reset.out	Thu Jan 29 22:00:07 2009 -0800
    11.3 @@ -1,22 +1,1 @@
    11.4  
    11.5 -
    11.6 -
    11.7 -
    11.8 -
    11.9 -
   11.10 -
   11.11 -
   11.12 -
   11.13 -
   11.14 -
   11.15 -
   11.16 -
   11.17 -
   11.18 -
   11.19 -
   11.20 -
   11.21 -
   11.22 -
   11.23 -
   11.24 -
   11.25 -

    12.1 --- a/en/examples/bisect.search.rest.out	Thu Jan 15 10:13:51 2009 +0100
    12.2 +++ b/en/examples/bisect.search.rest.out	Thu Jan 29 22:00:07 2009 -0800
    12.3 @@ -14,56 +14,3 @@
    12.4  
    12.5  
    12.6  
    12.7 -
    12.8 -
    12.9 -
   12.10 -
   12.11 -
   12.12 -
   12.13 -
   12.14 -
   12.15 -
   12.16 -
   12.17 -
   12.18 -
   12.19 -
   12.20 -
   12.21 -
   12.22 -
   12.23 -
   12.24 -
   12.25 -
   12.26 -
   12.27 -
   12.28 -
   12.29 -
   12.30 -
   12.31 -
   12.32 -
   12.33 -
   12.34 -
   12.35 -
   12.36 -
   12.37 -
   12.38 -
   12.39 -
   12.40 -
   12.41 -
   12.42 -
   12.43 -
   12.44 -
   12.45 -
   12.46 -
   12.47 -
   12.48 -
   12.49 -
   12.50 -
   12.51 -
   12.52 -
   12.53 -
   12.54 -
   12.55 -
   12.56 -
   12.57 -
   12.58 -
   12.59 -

    13.1 --- a/en/examples/bisect.search.step1.out	Thu Jan 15 10:13:51 2009 +0100
    13.2 +++ b/en/examples/bisect.search.step1.out	Thu Jan 29 22:00:07 2009 -0800
    13.3 @@ -9,22 +9,3 @@
    13.4  
    13.5  
    13.6  
    13.7 -
    13.8 -
    13.9 -
   13.10 -
   13.11 -
   13.12 -
   13.13 -
   13.14 -
   13.15 -
   13.16 -
   13.17 -
   13.18 -
   13.19 -
   13.20 -
   13.21 -
   13.22 -
   13.23 -
   13.24 -
   13.25 -

    14.1 --- a/en/examples/bisect.search.step2.out	Thu Jan 15 10:13:51 2009 +0100
    14.2 +++ b/en/examples/bisect.search.step2.out	Thu Jan 29 22:00:07 2009 -0800
    14.3 @@ -2,22 +2,3 @@
    14.4  
    14.5  
    14.6  
    14.7 -
    14.8 -
    14.9 -
   14.10 -
   14.11 -
   14.12 -
   14.13 -
   14.14 -
   14.15 -
   14.16 -
   14.17 -
   14.18 -
   14.19 -
   14.20 -
   14.21 -
   14.22 -
   14.23 -
   14.24 -
   14.25 -

    15.1 --- a/en/examples/branch-repo.bugfix.out	Thu Jan 15 10:13:51 2009 +0100
    15.2 +++ b/en/examples/branch-repo.bugfix.out	Thu Jan 29 22:00:07 2009 -0800
    15.3 @@ -5,7 +5,7 @@
    15.4  $ \textbf{echo 'I fixed a bug using only echo!' >> myfile}
    15.5  $ \textbf{hg commit -m 'Important fix for 1.0.1'}
    15.6  $ \textbf{hg push}
    15.7 -pushing to /tmp/branch-repo4rF-PL/myproject-1.0.1
    15.8 +pushing to 
    15.9  searching for changes
   15.10  adding changesets
   15.11  adding manifests

    16.1 --- a/en/examples/branching.stable.out	Thu Jan 15 10:13:51 2009 +0100
    16.2 +++ b/en/examples/branching.stable.out	Thu Jan 29 22:00:07 2009 -0800
    16.3 @@ -5,7 +5,7 @@
    16.4  $ \textbf{echo 'This is a fix to a boring feature.' > myfile}
    16.5  $ \textbf{hg commit -m 'Fix a bug'}
    16.6  $ \textbf{hg push}
    16.7 -pushing to /tmp/branchingfJgZac/stable
    16.8 +pushing to 
    16.9  searching for changes
   16.10  adding changesets
   16.11  adding manifests

    17.1 --- a/en/examples/daily.copy.merge.out	Thu Jan 15 10:13:51 2009 +0100
    17.2 +++ b/en/examples/daily.copy.merge.out	Thu Jan 29 22:00:07 2009 -0800
    17.3 @@ -7,7 +7,7 @@
    17.4  added 1 changesets with 1 changes to 1 files (+1 heads)
    17.5  (run 'hg heads' to see heads, 'hg merge' to merge)
    17.6  $ \textbf{hg merge}
    17.7 -merging file and new-file to new-file
    17.8 +merging file and new-file
    17.9  0 files updated, 1 files merged, 0 files removed, 0 files unresolved
   17.10  (branch merge, don't forget to commit)
   17.11  $ \textbf{cat new-file}

    18.1 --- a/en/examples/tour-merge-conflict.commit.out	Thu Jan 15 10:13:51 2009 +0100
    18.2 +++ b/en/examples/tour-merge-conflict.commit.out	Thu Jan 29 22:00:07 2009 -0800
    18.3 @@ -4,6 +4,29 @@
    18.4  > \textbf{Nigerian dictator Sani Abacha.}
    18.5  > \textbf{EOF}
    18.6  $ \textbf{hg resolve -m letter.txt}
    18.7 +hg: unknown command 'resolve'
    18.8 +Mercurial Distributed SCM
    18.9 +
   18.10 +basic commands:
   18.11 +
   18.12 + add        add the specified files on the next commit
   18.13 + annotate   show changeset information per file line
   18.14 + clone      make a copy of an existing repository
   18.15 + commit     commit the specified files or all outstanding changes
   18.16 + diff       diff repository (or selected files)
   18.17 + export     dump the header and diffs for one or more changesets
   18.18 + init       create a new repository in the given directory
   18.19 + log        show revision history of entire repository or files
   18.20 + merge      merge working directory with another revision
   18.21 + parents    show the parents of the working dir or revision
   18.22 + pull       pull changes from the specified source
   18.23 + push       push changes to the specified destination
   18.24 + remove     remove the specified files on the next commit
   18.25 + serve      export the repository via HTTP
   18.26 + status     show changed files in the working directory
   18.27 + update     update working directory
   18.28 +
   18.29 +use "hg help" for the full list of commands or "hg -v" for details
   18.30  $ \textbf{hg commit -m 'Send me your money'}
   18.31  $ \textbf{hg tip}
   18.32  changeset:   

    19.1 --- a/en/examples/tour-merge-conflict.merge.out	Thu Jan 15 10:13:51 2009 +0100
    19.2 +++ b/en/examples/tour-merge-conflict.merge.out	Thu Jan 29 22:00:07 2009 -0800
    19.3 @@ -4,7 +4,9 @@
    19.4  merge: warning: conflicts during merge
    19.5  merging letter.txt failed!
    19.6  0 files updated, 0 files merged, 0 files removed, 1 files unresolved
    19.7 -use 'hg resolve' to retry unresolved file merges
    19.8 +There are unresolved merges, you can redo the full merge using:
    19.9 +  hg update -C 1
   19.10 +  hg merge 2
   19.11  $ \textbf{cat letter.txt}
   19.12  Greetings!
   19.13  

    20.1 --- a/en/examples/tour.help.out	Thu Jan 15 10:13:51 2009 +0100
    20.2 +++ b/en/examples/tour.help.out	Thu Jan 29 22:00:07 2009 -0800
    20.3 @@ -3,7 +3,7 @@
    20.4  
    20.5  create a new repository in the given directory
    20.6  
    20.7 -    Initialize a new repository in the given directory. If the given
    20.8 +    Initialize a new repository in the given directory.  If the given
    20.9      directory does not exist, it is created.
   20.10  
   20.11      If no directory is given, the current directory is used.

    21.1 --- a/en/examples/tour.ls.out	Thu Jan 15 10:13:51 2009 +0100
    21.2 +++ b/en/examples/tour.ls.out	Thu Jan 29 22:00:07 2009 -0800
    21.3 @@ -1,5 +1,5 @@
    21.4  $ \textbf{ls -l}
    21.5 -total 4
    21.6 +
    21.7  
    21.8  $ \textbf{ls hello}
    21.9  Makefile  hello.c

    22.1 --- a/en/examples/tour.version.out	Thu Jan 15 10:13:51 2009 +0100
    22.2 +++ b/en/examples/tour.version.out	Thu Jan 29 22:00:07 2009 -0800
    22.3 @@ -1,5 +1,5 @@
    22.4  $ \textbf{hg version}
    22.5 -Mercurial Distributed SCM (version )
    22.6 +Mercurial Distributed SCM (version 1.0)
    22.7  
    22.8  Copyright (C) 2005-2008 Matt Mackall <mpm@selenic.com> and others
    22.9  This is free software; see the source for copying conditions. There is NO

    23.1 --- a/en/hook.tex	Thu Jan 15 10:13:51 2009 +0100
    23.2 +++ b/en/hook.tex	Thu Jan 29 22:00:07 2009 -0800
    23.3 @@ -509,7 +509,7 @@
    23.4  whitespace from a file.  This is concise and useful enough that I will
    23.5  reproduce it here.
    23.6  \begin{codesample2}
    23.7 -  perl -pi -e 's,\\s+\$,,' filename
    23.8 +  perl -pi -e 's,\textbackslash{}s+\$,,' filename
    23.9  \end{codesample2}
   23.10  
   23.11  \section{Bundled hooks}

    24.1 --- a/en/mq-collab.tex	Thu Jan 15 10:13:51 2009 +0100
    24.2 +++ b/en/mq-collab.tex	Thu Jan 29 22:00:07 2009 -0800
    24.3 @@ -275,7 +275,7 @@
    24.4    backports a piece of code to~2.6.9 will have a~\texttt{2.6.9} guard.
    24.5  \end{itemize}
    24.6  This variety of guards gives me considerable flexibility in
    24.7 -qdetermining what kind of source tree I want to end up with.  For most
    24.8 +determining what kind of source tree I want to end up with.  For most
    24.9  situations, the selection of appropriate guards is automated during
   24.10  the build process, but I can manually tune the guards to use for less
   24.11  common circumstances.

    25.1 --- a/en/mq.tex	Thu Jan 15 10:13:51 2009 +0100
    25.2 +++ b/en/mq.tex	Thu Jan 29 22:00:07 2009 -0800
    25.3 @@ -525,7 +525,7 @@
    25.4  modifies \filename{foo} with six hunks, and one of them fails to
    25.5  apply, you will have: an unmodified \filename{foo.orig}, a
    25.6  \filename{foo.rej} containing one hunk, and \filename{foo}, containing
    25.7 -the changes made by the five successful five hunks.
    25.8 +the changes made by the five successful hunks.
    25.9  
   25.10  \subsection{Some quirks of patch representation}
   25.11  

    26.1 --- a/en/template.tex	Thu Jan 15 10:13:51 2009 +0100
    26.2 +++ b/en/template.tex	Thu Jan 29 22:00:07 2009 -0800
    26.3 @@ -244,7 +244,7 @@
    26.4    date using the same format used in email headers.  Yields a string
    26.5    like ``\Verb+Mon, 04 Sep 2006 15:13:13 -0700+''.
    26.6  \item[\tplkwfilt{node}{short}] Changeset hash.  Yield the short form
    26.7 -  of a changeset hash, i.e.~a 12-byte hexadecimal string.
    26.8 +  of a changeset hash, i.e.~a 12-character hexadecimal string.
    26.9  \item[\tplkwfilt{date}{shortdate}] \tplkword{date} keyword.  Render
   26.10    the year, month, and day of the date.  Yields a string like
   26.11    ``\Verb+2006-09-04+''.
   26.12 @@ -452,7 +452,7 @@
   26.13  \item Subversion's output includes a count in the header of the number
   26.14    of lines in the commit message.  We cannot replicate this in
   26.15    Mercurial; the templating engine does not currently provide a filter
   26.16 -  that counts the number of items it is passed.
   26.17 +  that counts the number of lines the template generates.
   26.18  \end{itemize}
   26.19  It took me no more than a minute or two of work to replace literal
   26.20  text from an example of Subversion's output with some keywords and

    27.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    27.2 +++ b/es/00book.tex	Thu Jan 29 22:00:07 2009 -0800
    27.3 @@ -0,0 +1,81 @@
    27.4 +% The use of oneside here is a temporary hack; \marginpar entries
    27.5 +% don't show up on odd pages of PDF output without it.  Sigh.
    27.6 +\documentclass[oneside]{book}
    27.7 +\usepackage[spanish]{babel}
    27.8 +\usepackage{enumerate}
    27.9 +\usepackage{fullpage}
   27.10 +\usepackage{makeidx}
   27.11 +\usepackage{ifpdf}
   27.12 +\usepackage{graphicx}
   27.13 +\usepackage{pslatex}
   27.14 +\usepackage{fancyvrb}
   27.15 +\usepackage[utf8]{inputenc} %accents in spanish
   27.16 +% leave hyperref until last
   27.17 +\ifpdf
   27.18 +\usepackage[colorlinks=true,bookmarks=true,pdftitle={Distributed
   27.19 +  revision control with Mercurial},pdfsubject={Revision
   27.20 +  control},pdfkeywords={Mercurial, Revision control, Distributed
   27.21 +  revision control},pdfauthor={Bryan O'Sullivan}]{hyperref}
   27.22 +\fi
   27.23 +
   27.24 +\include{99defs}
   27.25 +
   27.26 +\title{Control Distribuido de Revisiones con Mercurial} \author{Bryan
   27.27 +  O'Sullivan}
   27.28 +\date{Copyright \copyright\ 2006, 2007 Bryan O'Sullivan.\\
   27.29 +  Este material puede distribuirse únicamente bajo los términos y
   27.30 +  condiciones establecidos en la versión 1.0 de la Licencia de Publicación
   27.31 +  Abierta (OPL). Refiérase por favor al apéndice~\ref{cha:opl} para encontrar el
   27.32 +  texto de la licencia.\\
   27.33 +  Este libro fue preparado a partir de
   27.34 +  \href{http://mercurial.intuxication.org/hg/mercurial_book_es}{rev~\input{build_id}}
   27.35 +  usando Mercurial \href{http://www.selenic.com/hg/}{rev~\input{hg_id}}.}
   27.36 +
   27.37 +\makeindex
   27.38 +
   27.39 +\begin{document}
   27.40 +\spanishdeactivate{<>"~}
   27.41 +\maketitle
   27.42 +
   27.43 +\addcontentsline{toc}{chapter}{Índice general}
   27.44 +\pagenumbering{roman}
   27.45 +\tableofcontents
   27.46 +\listoffigures
   27.47 +%\listoftables
   27.48 +
   27.49 +\pagenumbering{arabic}
   27.50 +
   27.51 +\include{preface}
   27.52 +\include{intro}
   27.53 +\include{tour-basic}
   27.54 +\include{tour-merge}
   27.55 +\include{concepts}
   27.56 +\include{daily}
   27.57 +\include{collab}
   27.58 +\include{filenames}
   27.59 +\include{branch}
   27.60 +\include{undo}
   27.61 +\include{hook}
   27.62 +\include{template}
   27.63 +\include{mq}
   27.64 +\include{mq-collab}
   27.65 +\include{hgext}
   27.66 +
   27.67 +\appendix
   27.68 +\include{cmdref}
   27.69 +\include{mq-ref}
   27.70 +\include{srcinstall}
   27.71 +\include{license}
   27.72 +\addcontentsline{toc}{chapter}{Bibliografía}
   27.73 +\bibliographystyle{alpha}
   27.74 +\bibliography{99book}
   27.75 +
   27.76 +\addcontentsline{toc}{chapter}{Índice alfabético}
   27.77 +\printindex
   27.78 +
   27.79 +\end{document}
   27.80 +
   27.81 +%%% Local Variables: 
   27.82 +%%% mode: latex
   27.83 +%%% TeX-master: t
   27.84 +%%% End: 

    28.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    28.2 +++ b/es/99book.bib	Thu Jan 29 22:00:07 2009 -0800
    28.3 @@ -0,0 +1,1 @@
    28.4 +../en/99book.bib
    28.5 \ No newline at end of file

    29.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    29.2 +++ b/es/99defs.tex	Thu Jan 29 22:00:07 2009 -0800
    29.3 @@ -0,0 +1,146 @@
    29.4 +% Bug ID.
    29.5 +\newcommand{\bug}[1]{\index{Base de datos de fallos de Mercurial
    29.6 +    !\href{http://www.selenic.com/mercurial/bts/issue#1}{fallo
    29.7 +      ~#1}}\href{http://www.selenic.com/mercurial/bts/issue#1}{Fallo de
    29.8 +      Mercurial No.~#1}}
    29.9 +
   29.10 +% File name in the user's home directory.
   29.11 +\newcommand{\tildefile}[1]{\texttt{\~{}/#1}}
   29.12 +
   29.13 +% File name.
   29.14 +\newcommand{\filename}[1]{\texttt{#1}}
   29.15 +
   29.16 +% Directory name.
   29.17 +\newcommand{\dirname}[1]{\texttt{#1}}
   29.18 +
   29.19 +% File name, with index entry.
   29.20 +% The ``s'' prefix comes from ``special''.
   29.21 +\newcommand{\sfilename}[1]{\index{\texttt{#1}, fichero}\texttt{#1}}
   29.22 +
   29.23 +% Directory name, with index entry.
   29.24 +\newcommand{\sdirname}[1]{\index{\texttt{#1}, directorio}\texttt{#1}}
   29.25 +
   29.26 +% Mercurial extension.
   29.27 +\newcommand{\hgext}[1]{\index{\texttt{#1}, extensi\'on}\texttt{#1}}
   29.28 +
   29.29 +% Command provided by a Mercurial extension.
   29.30 +\newcommand{\hgxcmd}[2]{\index{\texttt{#2}, comando (extensi\'on
   29.31 +\texttt{#1})}\index{\texttt{#1}, extensi\'on!comando \texttt{#2}}``\texttt{hg #2}''}
   29.32 +
   29.33 +% Mercurial command.
   29.34 +\newcommand{\hgcmd}[1]{\index{\texttt{#1}, comando}``\texttt{hg #1}''}
   29.35 +
   29.36 +% Mercurial command, with arguments.
   29.37 +\newcommand{\hgcmdargs}[2]{\index{\texttt{#1}, comando}``\texttt{hg #1 #2}''}
   29.38 +
   29.39 +\newcommand{\tplkword}[1]{\index{\texttt{#1}, palabra clave de
   29.40 +plantilla}\index{palabras clave de plantilla!\texttt{#1}}\texttt{#1}}
   29.41 +
   29.42 +\newcommand{\tplkwfilt}[2]{\index{\texttt{#1}, palabra clave de plantilla!filtro
   29.43 +\texttt{#2}}\index{filtros de plantilla!\texttt{#2}}\index{\texttt{#2}, filtro
   29.44 +de plantilla}\texttt{#2}}
   29.45 +
   29.46 +\newcommand{\tplfilter}[1]{\index{filtros de
   29.47 +plantilla!\texttt{#1}}\index{\texttt{#1}, filtro de plantilla}\texttt{#1}}
   29.48 +
   29.49 +% Shell/system command.
   29.50 +\newcommand{\command}[1]{\index{\texttt{#1}, comando de sistema}\texttt{#1}}
   29.51 +
   29.52 +% Shell/system command, with arguments.
   29.53 +\newcommand{\cmdargs}[2]{\index{\texttt{#1} comando de sistema}``\texttt{#1 #2}''}
   29.54 +
   29.55 +% Mercurial command option.
   29.56 +\newcommand{\hgopt}[2]{\index{\texttt{#1}, comando!opción \texttt{#2}}\texttt{#2}}
   29.57 +
   29.58 +% Mercurial command option, provided by an extension command.
   29.59 +\newcommand{\hgxopt}[3]{\index{\texttt{#2}, comando (extensión
   29.60 +\texttt{#1})!opción \texttt{#3}}\index{\texttt{#1}, extensión!comando
   29.61 +\texttt{#2}!opción\texttt{#3}}\texttt{#3}}
   29.62 +
   29.63 +% Mercurial global option.
   29.64 +\newcommand{\hggopt}[1]{\index{opciones globales!opción \texttt{#1}}\texttt{#1}}
   29.65 +
   29.66 +% Shell/system command option.
   29.67 +\newcommand{\cmdopt}[2]{\index{\texttt{#1}, comando!opción \texttt{#2}}\texttt{#2}}
   29.68 +
   29.69 +% Command option.
   29.70 +\newcommand{\option}[1]{\texttt{#1}}
   29.71 +
   29.72 +% Software package.
   29.73 +\newcommand{\package}[1]{\index{\texttt{#1}, paquete}\texttt{#1}}
   29.74 +
   29.75 +% Section name from a hgrc file.
   29.76 +\newcommand{\rcsection}[1]{\index{\texttt{hgrc}, fichero!sección \texttt{#1}}\texttt{[#1]}}
   29.77 +
   29.78 +% Named item in a hgrc file section.
   29.79 +\newcommand{\rcitem}[2]{\index{\texttt{hgrc}, fichero!sección
   29.80 +\texttt{#1}!entrada \texttt{#2}}\texttt{#2}}
   29.81 +
   29.82 +% hgrc file.
   29.83 +\newcommand{\hgrc}{\index{fichero de configuración!\texttt{hgrc}
   29.84 +    (Linux/Unix)}\index{\texttt{hgrc}, fichero de configuración}\texttt{hgrc}}
   29.85 +
   29.86 +% Mercurial.ini file.
   29.87 +\newcommand{\hgini}{\index{fichero de configuración!\texttt{Mercurial.ini}
   29.88 +    (Windows)}\index{\texttt{Mercurial.ini}, fichero de configuración}\texttt{Mercurial.ini}}
   29.89 +
   29.90 +% Hook name.
   29.91 +\newcommand{\hook}[1]{\index{\texttt{#1}, gancho}\index{ganchos!\texttt{#1}}\texttt{#1}}
   29.92 +
   29.93 +% Environment variable.
   29.94 +\newcommand{\envar}[1]{\index{\texttt{#1}, variable de entorno}\index{variables
   29.95 +de entorno!\texttt{#1}}\texttt{#1}}
   29.96 +
   29.97 +% Python module.
   29.98 +\newcommand{\pymod}[1]{\index{\texttt{#1}, módulo}\texttt{#1}}
   29.99 +
  29.100 +% Python class in a module.
  29.101 +\newcommand{\pymodclass}[2]{\index{\texttt{#1}, módulo!clase \texttt{#2}}\texttt{#1.#2}}
  29.102 +
  29.103 +% Python function in a module.
  29.104 +\newcommand{\pymodfunc}[2]{\index{\texttt{#1}, módulo!función \texttt{#2}}\texttt{#1.#2}}
  29.105 +
  29.106 +% Note: blah blah.
  29.107 +\newsavebox{\notebox}
  29.108 +\newenvironment{note}%
  29.109 +  {\begin{lrbox}{\notebox}\begin{minipage}{0.7\textwidth}\textbf{Nota:}\space}%
  29.110 +  {\end{minipage}\end{lrbox}\fbox{\usebox{\notebox}}}
  29.111 +\newenvironment{caution}%
  29.112 +  {\begin{lrbox}{\notebox}\begin{minipage}{0.7\textwidth}\textbf{Precaución:}\space}%
  29.113 +  {\end{minipage}\end{lrbox}\fbox{\usebox{\notebox}}}
  29.114 +
  29.115 +% Code sample, eating 4 characters of leading space.
  29.116 +\DefineVerbatimEnvironment{codesample4}{Verbatim}{frame=single,gobble=4,numbers=left,commandchars=\\\{\}}
  29.117 +
  29.118 +% Code sample, eating 2 characters of leading space.
  29.119 +\DefineVerbatimEnvironment{codesample2}{Verbatim}{frame=single,gobble=2,numbers=left,commandchars=\\\{\}}
  29.120 +
  29.121 +% Interaction from the examples directory.
  29.122 +\newcommand{\interaction}[1]{\VerbatimInput[frame=single,numbers=left,commandchars=\\\{\}]{examples/#1.lxo}}
  29.123 +% Example code from the examples directory.
  29.124 +\newcommand{\excode}[1]{\VerbatimInput[frame=single,numbers=left,commandchars=\\\{\}]{../examples/#1}}
  29.125 +
  29.126 +% Graphics inclusion.
  29.127 +\ifpdf
  29.128 +  \newcommand{\grafix}[2][]{\includegraphics[#1]{#2}}
  29.129 +\else
  29.130 +  \newcommand{\grafix}[1]{\includegraphics{#1.png}}
  29.131 +\fi
  29.132 +
  29.133 +% Reference entry for a command.
  29.134 +\newcommand{\cmdref}[2]{\section{\hgcmd{#1}---#2}\label{cmdref:#1}\index{\texttt{#1}, comando}}
  29.135 +
  29.136 +% Reference entry for a command option with long and short forms.
  29.137 +\newcommand{\optref}[3]{\subsubsection{\hgopt{#1}{--#3}, también \hgopt{#1}{-#2}}}
  29.138 +
  29.139 +% Reference entry for a command option with only long form.
  29.140 +\newcommand{\loptref}[2]{\subsubsection{opción \hgopt{#1}{--#2}}}
  29.141 +
  29.142 +% command to generate a footnote to be used as a translator's note
  29.143 +\newcommand{\ndt}[1]{\footnote{\textbf{N. del T.} #1}}
  29.144 +
  29.145 +
  29.146 +%%% Local Variables: 
  29.147 +%%% mode: latex
  29.148 +%%% TeX-master: "00book"
  29.149 +%%% End: 

    30.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    30.2 +++ b/es/Leame.1st	Thu Jan 29 22:00:07 2009 -0800
    30.3 @@ -0,0 +1,508 @@
    30.4 += Parámetros de Organización =
    30.5 +
    30.6 + * Se mantienen los nombres de los archivos
    30.7 + * Se traduce solamente el contenido
    30.8 + * Copie los archivos de en a es y tradúzcalos
    30.9 + * Las gráficas son tan importantes como los archivos
   30.10 + de texto, ya han sido traducidas
   30.11 + * Encoding UTF-8 para las tildes, eñes y demás
   30.12 + * Ancho de línea de 70 caracteres
   30.13 +
   30.14 += ¿Cómo contribuir? =
   30.15 +Obtenga la copia :
   30.16 +hg clone http://mercurial.intuxication.org/hg/mercurial_book_es/
   30.17 +
   30.18 +Esto le ofrecerá un clon del repositorio en el directorio recién 
   30.19 +creado '''mercurial_book_es''':
   30.20 +
   30.21 +mercurial_book_es
   30.22 +|
   30.23 +|-- en
   30.24 +|-- es
   30.25 +|-- examples
   30.26 +|-- html
   30.27 +`-- sillybench
   30.28 +
   30.29 +El directorio de trabajo es '''es'''.
   30.30 +
   30.31 +
   30.32 +Una vez que haya traducido o aplicado correcciones a los archivos de
   30.33 +su copia local, haga un commit
   30.34 +
   30.35 + hg commit -m "comentario descriptivo de lo que hizo"
   30.36 +
   30.37 +Siempre mantenga actualizado su repositorio local
   30.38 + hg pull
   30.39 + hg update
   30.40 +
   30.41 +Hay dos formas de hacer la contribución, primero envíe un correo a
   30.42 +igor@tamarapatino.org indicando lo que desea hacer, se le puede
   30.43 +otorgar permiso de escritura en el repositorio, o si lo prefiere,
   30.44 +puede enviar un parche (patch).  Describimos a continuación los dos
   30.45 +procedimientos : Repositorio Público y Parches.   Es preferible el
   30.46 +repositorio público frente a los parches, puesto que estos segundos
   30.47 +pueden tardar en propagarse más.
   30.48 +
   30.49 +== Repositorio Público ==
   30.50 +Este sería el método preferido para que los cambios que usted haga
   30.51 +automáticamente queden en el repositorio y todos los traductores
   30.52 +podamos contar con la información rápidamente.
   30.53 +
   30.54 +Una vez que usted haya recibido la información necesaria, habiendo
   30.55 +elegido su usuario y su clave podrá "publicar" (push).
   30.56 +
   30.57 +Como este es un sistema distribuido, después de hacer la
   30.58 +consignación (commit), deberá publicarlo.
   30.59 +
   30.60 + hg push
   30.61 +
   30.62 +Se le solicitará su usuario y clave.
   30.63 +
   30.64 +== Parches ==
   30.65 +Este método exige que alguien reciba el parche y haga manualmente la
   30.66 +aplicación del mismo, ese alguien es igor@tamarapatino.org por ahora,
   30.67 +después de haber hecho commit en su repositorio local, revise su log.
   30.68 +
   30.69 + hg log | head
   30.70 +
   30.71 +Esta última orden le permitirá establecer la última revisión que se
   30.72 +consignó en su repositorio local, su identificador de revisión tendrá
   30.73 +el formato número:hash.   Generaría el archivo 
   30.74 +/tmp/patchparahgbook.patch con la orden
   30.75 +
   30.76 + hg -o /tmp/patchparahgbook.patch REV
   30.77 +
   30.78 +donde REV es el identificador de revisión que debió haber encontrado.
   30.79 +
   30.80 += Traducción/Revisión =
   30.81 +
   30.82 +En esta sección indicamos quienes están traduciendo
   30.83 +y quienes revisando lo traducido. Coloque su nombre 
   30.84 +para que los demás colaboradores sepan en dónde 
   30.85 +enfocar sus esfuerzos.
   30.86 +
   30.87 +Indique qué archivos está traduciendo y/o revisando en 
   30.88 +la lista siguiente. Cada archivo debe ser traducido y
   30.89 +revisado antes de poder considerarlo terminado. El revisor
   30.90 +no puede ser la misma persona que hizo la traducción.
   30.91 +
   30.92 +Cada traductor puede traducir o revisar el archivo que
   30.93 +desee, teniendo siempre en cuenta los archivos que ya tengan
   30.94 +alguien a cargo y escogiendo en la medida de lo posible
   30.95 +otros que no lo tengan. Los arreglos de 'typos' y problemas
   30.96 +de ortografía son siempre bienvenidos.
   30.97 +
   30.98 +== Archivos en proceso de traducción ==
   30.99 +||'''archivo'''    ||'''traductor'''||'''Estado'''||'''Inicio'''||  '''Fin'''  ||
  30.100 +|| 00book.tex      || Igor Támara   ||    100%    || 16/10/2008 ||  16/10/2008 ||
  30.101 +|| preface.tex     || Javier Rojas  ||    100%    || 18/10/2008 ||  19/10/2008 ||
  30.102 +|| intro.tex       || Igor Támara   ||	  100%	  || 08/11/2008	||  09/11/2008 ||
  30.103 +|| tour-basic.tex  || Javier Rojas  ||    100%    || 19/10/2008 ||  27/10/2008 ||
  30.104 +|| tour-merge.tex  || Javier Rojas  ||    100%    || 28/10/2008 ||  03/11/2008 ||
  30.105 +|| concepts.tex    || Javier Rojas  ||    100%    || 03/11/2008 ||  23/11/2008 ||
  30.106 +|| daily.tex       || Igor Támara   ||    100%    || 19/10/2008 ||  26/10/2008 ||
  30.107 +|| collab.tex      || Igor Támara   ||    100%    || 10/11/2008 ||  06/12/2008 ||
  30.108 +|| filenames.tex   || Javier Rojas  ||    100%    || 27/11/2008 ||  12/01/2008 ||
  30.109 +|| branch.tex      || Igor Támara   ||    100%    || 16/10/2008 ||  19/10/2008 ||
  30.110 +|| undo.tex        || Igor Támara   ||    100%    || 26/10/2008 ||  07/11/2008 ||
  30.111 +|| hook.tex        || Javier Rojas  ||    100%    || 01/12/2008 ||  04/01/2009 ||
  30.112 +|| template.tex    || Igor Támara   ||    100%    || 27/12/2008 ||  01/01/2009 ||
  30.113 +|| mq.tex          || Igor Támara   ||    100%    || 06/12/2008 ||  13/12/2008 ||
  30.114 +|| mq-collab.tex   || Javier Rojas  ||    100%    || 04/01/2009 ||  08/01/2009 ||
  30.115 +|| hgext.tex       || Igor Támara   ||    100%    || 13/12/2008 ||  16/12/2008 ||
  30.116 +|| cmdref.tex      || Igor Támara   ||    100%    || 01/01/2009 ||  01/01/2009 ||
  30.117 +|| mq-ref.tex      || Igor Támara   ||    100%    || 06/01/2009 ||  10/01/2009 ||
  30.118 +|| srcinstall.tex  || Igor Támara   ||    100%    || 01/01/2009 ||  01/01/2009 ||
  30.119 +|| license.tex     || Igor Támara   ||    100%    || 16/12/2008 ||  16/12/2008 ||
  30.120 +
  30.121 +== Archivos en proceso de revisión ==
  30.122 +||'''archivo'''   || '''revisor''' ||'''Estado'''||'''Inicio'''||  '''Fin'''  ||
  30.123 +|| 00book.tex     || Javier Rojas  ||    100%    || 18/01/2009 ||  18/01/2009 ||
  30.124 +|| branch.tex     || Javier Rojas  ||    100%    || 25/01/2009 ||  25/01/2009 ||
  30.125 +|| preface.tex    ||               ||            ||            ||             ||
  30.126 +|| daily.tex      || Javier Rojas  ||    100%    || 25/01/2009 ||  29/01/2009 ||
  30.127 +|| tour-basic.tex ||               ||            ||            ||             ||
  30.128 +|| undo.tex       || Javier Rojas  ||            ||            ||             ||
  30.129 +|| tour-merge.tex ||               ||            ||            ||             ||
  30.130 +|| concepts.tex   ||               ||            ||            ||             ||
  30.131 +|| intro.tex      || Javier Rojas  ||    100%    || 12/01/2009 ||  12/01/2009 ||
  30.132 +|| collab.tex     || Javier Rojas  ||      0%    || 29/01/2009 ||             ||
  30.133 +|| mq.tex         ||               ||            ||            ||             ||
  30.134 +|| hgext.tex      ||               ||            ||            ||             ||
  30.135 +|| template.tex   ||               ||            ||            ||             ||
  30.136 +|| mq-collab.tex  ||               ||            ||            ||             ||
  30.137 +|| mq-ref.tex     ||               ||            ||            ||             ||
  30.138 +|| cmdref.tex     ||               ||            ||            ||             ||
  30.139 +|| license.tex    ||               ||            ||            ||             ||
  30.140 +|| srcinstall.tex ||               ||            ||            ||             ||
  30.141 +
  30.142 +== Archivos terminados ==
  30.143 +||'''archivo'''   ||'''Inicio'''||  '''Fin'''  ||
  30.144 +|| 00book.tex     || 16/10/2008 ||  18/01/2009 ||
  30.145 +|| intro.tex      || 08/11/2008 ||  12/01/2009 ||
  30.146 +|| branch.tex     || 16/10/2008 ||  25/01/2009 ||
  30.147 +|| daily.tex      || 19/10/2008 ||  29/01/2009 ||
  30.148 +
  30.149 += Unificación de Términos de Traducción =
  30.150 +Por favor mantenga esta lista en orden alfabético
  30.151 +
  30.152 +La mayor parte del texto a continuación fue tomado del glosario de la
  30.153 +traducción del libro de subversion al idioma español.
  30.154 +
  30.155 +Pequeño glosario de términos traducidos. Aquí deben ponerse esos
  30.156 +"bonitos palabros" que tanto nos ha costado traducir para evitar
  30.157 +inconsistencias en la traducción por varias personas. Normalmente
  30.158 +son técnicos, pero puede incluirse cualquier "giro" o expresión que
  30.159 +consideremos útil mantener y repetir a lo largo de la traducción.
  30.160 +En el libro final posiblemente se añada una versión de este fichero
  30.161 +como apéndice.
  30.162 +
  30.163 +Para incluir algo, hay que especificar la expresión en inglés, su
  30.164 +versión traducida, y una pequeña explicación como justificación.
  30.165 +
  30.166 + Alice: Alicia
  30.167 + Anne: Ana
  30.168 + Back out: Retroceder
  30.169 + Binary test: Prueba binaria
  30.170 + Bob : Roberto
  30.171 + Branch: Rama
  30.172 + Bug: Fallo
  30.173 + Build Script: Guión de construcción
  30.174 + Builtin: integrada/o
  30.175 + Bundle: Agrupamiento 
  30.176 + Bundled: Incluído o agrupado
  30.177 + Changelog: Bitácora de Cambios
  30.178 + Changeset: Conjunto de Cambios
  30.179 + Command: Orden
  30.180 + Commit: Consignar
  30.181 + Core: alma
  30.182 + Directory: Directorio
  30.183 + Escape Sequence: Secuencia de control
  30.184 + File: fichero
  30.185 + Filelog: fichero de registro
  30.186 + Fold: Integrar
  30.187 + Fork: Bifurcación
  30.188 + Hash: No se traduce
  30.189 + Head: Principal. En el contexto de revisiones HEAD se sugiere usar "frente"
  30.190 + Hook: Gancho
  30.191 + Merge: Fusión
  30.192 + Milestone: Etapa
  30.193 + Mistake: Equivocación, cometida por un humano
  30.194 + Output: salida o despliegue
  30.195 + Patch: Parche
  30.196 + Path: Ruta de archivo
  30.197 + Pointer: apuntador
  30.198 + Pop: Sustraer, la contraparte push, será publicar
  30.199 + Probe: Sondeo
  30.200 + Pull: Jalar
  30.201 + Push: Publicar.  En el contexto de parches introducir.
  30.202 + Queue: Cola
  30.203 + Release: Versión o liberación de versión
  30.204 + Revlog: Bitácora de revisiones
  30.205 + Roll back: NO se traduce Ver más abajo
  30.206 + Snapshot: instantánea
  30.207 + Snippet: Recorte de código
  30.208 + Stack: pila
  30.209 + Stripped: 
  30.210 + Sprint: sprint
  30.211 + Tarball: paquete de cambios
  30.212 + Timestamp : marca de tiempo
  30.213 + Tip: punta
  30.214 + Update: actualización
  30.215 + Upstream: principal, mantenedor principal. De acuerdo al contexto.
  30.216 +
  30.217 +abort -> cancelar
  30.218 +
  30.219 +ancestry -> ascendencia
  30.220 +    La traducción literal concuerda con el significado que se le
  30.221 +    da al mismo término en la jerga de Subversion.
  30.222 +
  30.223 +API, GUI -> no se traduce
  30.224 +    La primera vez que aparecen, poner nota del traductor indicando
  30.225 +    qué significan las siglas y su traducción al castellano. De
  30.226 +    hecho, verificar la aparición de las notas de traductor en el
  30.227 +    sitio correcto debería ser una entrada del fichero TODO...
  30.228 +
  30.229 +back-end -> ???
  30.230 +    Se refiere al término opuesto de front-end. En el octavo
  30.231 +    capítulo se usa al menos tres veces para referirse al "motor"
  30.232 +    que hay detrás de la capa de base de datos. Hmmm... pero motor
  30.233 +    suena raro...
  30.234 +
  30.235 +backup -> copia de seguridad
  30.236 +    Obtenido del glosario ORCA.
  30.237 +
  30.238 +Blanket Access Control -> Control de acceso simple
  30.239 +    Por ahora no se me ocurre mejor traducción. Aquí blanket se
  30.240 +    refiere a un control muy genérico, con poca granularidad.
  30.241 +
  30.242 +branching and merging -> crear ramas y fusionarlas
  30.243 +    Aunque branch está bien traducido como rama o rama de desarrollo
  30.244 +    (en su versión "verbose"), no hay forma de hacer de un sustantivo
  30.245 +    un verbo.  Por lo tanto, se crean, borran y fusionan ramas.
  30.246 +
  30.247 +browse -> navegar
  30.248 +    Usado con frecuencia para navegar por directorios o repositorios.
  30.249 +
  30.250 +build -> comodín
  30.251 +    No es que se traduzca como comodín, sino que en función del
  30.252 +    contexto es una de esas palabras que significan muchas cosas y
  30.253 +    no es posible traducirla literalmente. Por ejemplo, cuando se
  30.254 +    usa como verbo se suele referir a compilar código fuente. En
  30.255 +    cambio, cuando se usa como sustantivo se suele referir a una
  30.256 +    versión particular del fichero binario ejecutable de un software,
  30.257 +    resultado de una compilación previa. Cuidado con esto. Anotar
  30.258 +    aquí traducciones realizadas para comparar.
  30.259 +
  30.260 +        ...using and building Subversion...
  30.261 +        ...usando y compilando Subversion...
  30.262 +
  30.263 +changeset -> ???
  30.264 +    Aparentemente conjunto de cambios. No puede ser traducido
  30.265 +    como parche, el libro inglés indica que un "changeset" es un
  30.266 +    parche con nombre único. Por ahora dejar en "changeset", ya se
  30.267 +    buscará algo en el futuro. Para ver la descripción del libro,
  30.268 +    buscar en ch04.xml la frase "Subversion y los changesets".
  30.269 +
  30.270 +cheap copy -> copia ligera
  30.271 +    Otras posibilidades barajadas son copia barata o liviana.
  30.272 +    Veremos si en el futuro éstas suenan mejor.
  30.273 +
  30.274 +click -> haga clic, pulse
  30.275 +    Traducción obtenida del glosario. Parece ser que click sólo se
  30.276 +    deja tal cual cuando se refiere a un sonido mecánico. Cuando
  30.277 +    se refiere a pulsar el botón del ratón se traduce como clic.
  30.278 +
  30.279 +CVS -> No se traduce
  30.280 +
  30.281 +DAV share -> recurso DAV compartido
  30.282 +    No tengo ni idea de lo que es un DAV share, así que cuando me
  30.283 +    entere (o alguien lo haga), que cambie esta entrada del glosario.
  30.284 +
  30.285 +directory -> directorio
  30.286 +    Entre carpeta y directorio se prefiere directorio.
  30.287 +
  30.288 +email -> correo electrónico
  30.289 +    Entre las posibilidades de dejar la palabra tal cual, añadir un
  30.290 +    guión (e-mail) y poner la traducción, se prefiere la traducción
  30.291 +    completa.
  30.292 +
  30.293 +FAQ -> FAQ
  30.294 +    Se deja tal cual pues se explica en el primer párrafo del prólogo
  30.295 +    como una nota del traductor, y porque es muy frecuente ver su
  30.296 +    uso en español. PyRF, PUFs o PFs son realmente desconcertantes.
  30.297 +
  30.298 +file -> fichero
  30.299 +    Entre archivo y fichero se prefiere fichero.
  30.300 +
  30.301 +file path -> ruta del fichero
  30.302 +    Cuando se ve path a secas, la forma más común de traducirlo
  30.303 +    es decir ruta a secas igualmente. Bueno, el glosario de ORCA
  30.304 +    también da como válidos camino y trayectoria. A ser posible
  30.305 +    usar ruta si el contexto de la frase así lo favorece, en caso
  30.306 +    contrario probar con camino o trayectoria.
  30.307 +
  30.308 +hash table -> tabla hash
  30.309 +    Sugerido por Miguel Pérez Ibars. También encontrado en el
  30.310 +    glosario ORCA.
  30.311 +
  30.312 +history -> Depende del contexto. Cuando se use en el contexto del repositorio
  30.313 +    (the history of the repository), debe usarse el término historial. En otro
  30.314 +    caso, historia. Valga anotar que ambas traducciones son aceptadas (al menos
  30.315 +    en wordreference.com).
  30.316 +
  30.317 +hook, to hook -> gancho, enganchar
  30.318 +    Usado en terminología de programación para indicar que el usuario
  30.319 +    tiene un mecanismo estándar para modificar el comportamiento de
  30.320 +    un dispositivo existente. Un ejemplo a nivel de programación
  30.321 +    son las funciones "callback" que se pasan como parámetros,
  30.322 +    o a nivel de sistema, scripts que existen en un directorio
  30.323 +    concreto y que se ejecutan por el servidor de Subversion para
  30.324 +    realizar tareas personalizadas por el administrador.
  30.325 +
  30.326 +ignore pattern -> ignorar patrones, pero patrones de exclusión
  30.327 +    Subversion permite que ciertas opciones almacenen patrones
  30.328 +    con los que se ignoran ficheros no versionados. Cuando la
  30.329 +    frase original usa el verbo, se puede traducir como ignorar
  30.330 +    directamente, pero cuando se usa a modo de sustantivo,
  30.331 +    es mejor traducirlo como "patrón de exclusión" en lugar de
  30.332 +    "patrón a ignorar".
  30.333 +
  30.334 +language -> lenguaje o idioma
  30.335 +    Precisamente para diferenciar si nos estamos refiriendo a un
  30.336 +    lenguaje de programación o a un lenguaje hablado por humanos,
  30.337 +    se usará idioma en este último caso.
  30.338 +
  30.339 +language binding, SWIG binding, wrapper -> interfaz, enlace, ligadura, envoltorio...
  30.340 +    Dependiendo del contexto, y desde un punto de vista personal,
  30.341 +    se puede traducir esta palabra de muchas maneras. Una manera
  30.342 +    genérica es decir "Interfaz con el lenguaje X", o "Ligadura con
  30.343 +    el lenguaje X". Habitualmente, cuando se habla de una interfaz,
  30.344 +    se está hablando de un binding ligero, o que únicamente permite
  30.345 +    a hacer llamadas a funciones del lenguaje de programación A
  30.346 +    desde el lenguaje de programación B.
  30.347 +
  30.348 +    En cambio, se suele hablar de wrapper cuando el código entre
  30.349 +    el lenguaje A y B es algo más complejo, o adapta el estilo de
  30.350 +    programación del lenguaje A al del lenguaje B. Un ejemplo de esto
  30.351 +    último sería una librería en C cuyo binding en Perl/Ruby/Python
  30.352 +    fuese orientado a objetos.
  30.353 +
  30.354 +    Aparte, wrapper también se usa cuando se habla de una función
  30.355 +    o librería que engloba o asimila otra menor, con el propósito
  30.356 +    de extender su funcionalidad o hacerla más fácil de usar
  30.357 +    de cara al usuario, sin necesidad de cruzar ninguna barrera
  30.358 +    "intra-lenguaje".
  30.359 +
  30.360 +    Por lo tanto, hay que decidir con cuidado el contexto de la
  30.361 +    palabra binding o wrapper, y escoger una. En el capítulo octavo
  30.362 +    hay varios usos, aunque como son relativos a SWIG, se habla de
  30.363 +    interfaces o envoltorios simplificados, puesto que se generan
  30.364 +    de manera automática y no hay ninguna "conversión" en el estilo
  30.365 +    de uso.
  30.366 +
  30.367 +lazy copy -> copia vaga
  30.368 +    Horrible traducción literal. ¿Sugerencias?
  30.369 +    copia perezosa
  30.370 +
  30.371 +location (repository) -> ubicación (del repositorio)
  30.372 +    Cuidado, no traducir como localización, que es la acción y
  30.373 +    efecto de localizar.
  30.374 +
  30.375 +log, log message -> informe de cambios, mensaje del informe de cambios
  30.376 +    Traducción extraída del manual de CVS en español. La traducción
  30.377 +    de "log message" es muy larga, pero únicamente porque no se
  30.378 +    tiene contexto alguno. Con contexto suele ser posible omitir
  30.379 +    la palabra informe si se considera apropiado.
  30.380 +
  30.381 +memory pool -> área de memoria
  30.382 +    Traducción temporal hasta que se revise algún libro en castellano
  30.383 +    de programación que use el mismo término.
  30.384 +
  30.385 +merge -> fusionar cambios, fusión
  30.386 +    Obtenida referencia del manual de CVS en castellano, la otra
  30.387 +    alternativa obvia para traducir merge es mezclar. No obstante,
  30.388 +    mezclar tiene una connotación de azar al realizar la mezcla. Se
  30.389 +    mezclan líquidos, ingredientes, etc. En cambio, un "merge" es
  30.390 +    cualquier cosa menos un proceso realizado al azar (especialmente
  30.391 +    si ha habido conflictos). En caso de traducir como sustantivo,
  30.392 +    fusión vuelve a "sonar mejor" que mezcla, que por alguna razón me
  30.393 +    suena a un combustible especial usado en vehículos de transporte.
  30.394 +
  30.395 +namespace -> espacio de nombrado,
  30.396 +    Tecnicismo del C++, obtenido de la traducción del libro
  30.397 +    "Pensar en C++", en concreto la sección 3.2 disponible en
  30.398 +    http://arco.inf-cr.uclm.es/~dvilla/pensar_en_C++/ch02s03.html#id2589039.
  30.399 +
  30.400 +open source -> código fuente abierto
  30.401 +    Referencia: http://es.tldp.org/ORCA/glosario.html#O
  30.402 +
  30.403 +plugins -> módulos
  30.404 +    El término fue extraído del glosario de ORCA.
  30.405 +
  30.406 +repository -> repositorio
  30.407 +    No hay mucha alternativa, ¿verdad?
  30.408 +
  30.409 +roll back -> No se traduce 
  30.410 +    El significado igual que en los ambientes
  30.411 +     de sistemas manejadores de bases de datos se refiere a la atomicidad
  30.412 +     e integridad al devolver un conjunto de acciones que permitan dejar
  30.413 +     el repositorio en un estado consistente previo.
  30.414 +
  30.415 +repository layou t-> estructura del repositorio En referencia a cómo
  30.416 +    están organizados los directorios.
  30.417 +
  30.418 +schedule -> programa o planifica
  30.419 +    Parece más correcta la opción programa, en el sentido de pensar en
  30.420 +    hacer algo.
  30.421 +    schedule foo to be added -> programa la adición de foo
  30.422 +
  30.423 +switch -> cambiar
  30.424 +    Únicamente cuando se habla del comando svn switch, no como la
  30.425 +    palabra switch aislada, que significa parámetro o interruptor.
  30.426 +    En el contexto de svn switch, traducirlo como cambiar. Quizás
  30.427 +    traducir como reubicar una vez haya suficiente material traducido
  30.428 +    y una lectura final sugiera una u otra traducción.
  30.429 +
  30.430 +tag, tagging -> etiqueta, etiquetar
  30.431 +    Expresión ya común en español.
  30.432 +
  30.433 +three-way differencing program -> programa de diferenciación a tres bandas
  30.434 +    Una diferenciación "normal" es generar las diferencias entre
  30.435 +    dos ficheros.  Una diferenciación a tres bandas es comparar las
  30.436 +    diferencias entre tres ficheros, y se usa cuando se intentan
  30.437 +    fusionar los cambios de una copia local junto con los cambios
  30.438 +    recibidos del repositorio (por ejemplo, otra persona ha cambiado
  30.439 +    el fichero sobre el que trabajábamos).
  30.440 +
  30.441 +timestamp, datestamp -> marca de tiempo, fecha y hora
  30.442 +    Esa traducción viene del ORCA. No obstante en muchos casos es
  30.443 +    más claro traducirla como "fecha de fichero" o "fecha" a secas.
  30.444 +    Ejemplo: ...will show the modification timestamp. -> mostrará
  30.445 +    la fecha de modificación. Decir "mostrará la marca de tiempo de
  30.446 +    la modificación" o algo así es una traducción demasiado literal,
  30.447 +    así que ojo con el contexto.
  30.448 +
  30.449 +track -> seguir, monitorear
  30.450 +    este término suele ser usado cuando se habla de archivos, y de llevar la 
  30.451 +    pista o monitorear los cambios en un archivo.
  30.452 +
  30.453 +trunk -> tronco
  30.454 +    Se refiere al nombre que recibe la línea de desarrollo
  30.455 +    principal del repositorio que no está asociada a ninguna rama
  30.456 +    en particular. Traducción obtenida del manual de CVS en español.
  30.457 +
  30.458 +Unix-like systems -> sistemas tipo unix
  30.459 +
  30.460 +URL -> No se traduce
  30.461 +
  30.462 +working copy -> copia (de trabajo) local/activa
  30.463 +    Traducción similar a la de "commit data" (razonamiento
  30.464 +    cliente-servidor).
  30.465 +
  30.466 += Términos a no-usar =
  30.467 +Evite el uso de estos términos en la traducción aún si son de uso
  30.468 +común para usted; el consenso general de la comunidad hispana puede
  30.469 +ser diferente del que usted tenga ;)
  30.470 +
  30.471 +  * "archivo". Use "fichero" en su lugar.
  30.472 +  * "carpeta". Use "directorio".
  30.473 +  * "la historia". Use "el historial" (por supuesto, cuando se refiera al
  30.474 +  historial del repositorio)
  30.475 +
  30.476 += Diferencias de redacción =
  30.477 +Hay varias expresiones que pueden terminar siendo traducidas de formas
  30.478 +diferentes por los traductores, y que aún siendo ambas correctas, ponen en
  30.479 +evidencia que el trabajo fue llevado a cabo por varias personas y que el estilo
  30.480 +que ellas usan difiere. Una vez terminada la traducción habrá que buscar cuáles
  30.481 +son éstos términos y decidirse por uno solo de ellos. A continuación se presenta
  30.482 +una lista de los términos o expresiones encontrados hasta ahora
  30.483 +
  30.484 +  * comando - orden. Ambos son la traducción para "command". Parece que la
  30.485 +  traducción más adecuada es "comando"
  30.486 +  (http://www.wordreference.com/es/translation.asp?tranword=command)
  30.487 +  * kernel - núcleo.
  30.488 +  * Colas de Mercurial - colas de Mercurial. Creo que lo mejor es revisar qué
  30.489 +  usó el autor (y rogar que él no haya sido inconsistente :P)
  30.490 +  * armar - compilar - construir. Build, compile. Más que todo "build"
  30.491 +  * daemonio - demonio. daemon
  30.492 +  * kernel - núcleo.
  30.493 +  * la URL - el URL
  30.494 +
  30.495 += Notas del traductor =
  30.496 +Por favor use el comando \ndt para insertar notas del traductor. Este
  30.497 +comando requiere un argumento. Por ejemplo: \ndt{Del inglés del original.}
  30.498 +
  30.499 += Para compilar =
  30.500 +He aquí algunas dependencias para Debian:
  30.501 +
  30.502 +apt-get install texlive-latex-extra tex4ht diffstat patchutils \ 
  30.503 +   inkscape graphviz texlive-pdfetex
  30.504 +
  30.505 += Traductores =
  30.506 +Por favor mantenga esta lista en orden alfabético de acuerdo al
  30.507 +apellido.
  30.508 +
  30.509 + * Javier Rojas <jerojasro@devnull.li>
  30.510 + * Igor Támara <igor@tamarapatino.org>
  30.511 + * Su nombre <su@e.mail>

    31.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    31.2 +++ b/es/Makefile	Thu Jan 29 22:00:07 2009 -0800
    31.3 @@ -0,0 +1,223 @@
    31.4 +# This makefile requires GNU make.
    31.5 +
    31.6 +sources := \
    31.7 +	00book.tex \
    31.8 +	99book.bib \
    31.9 +	99defs.tex \
   31.10 +	build_id.tex \
   31.11 +	branch.tex \
   31.12 +	cmdref.tex \
   31.13 +	collab.tex \
   31.14 +	concepts.tex \
   31.15 +	daily.tex \
   31.16 +	filenames.tex \
   31.17 +	hg_id.tex \
   31.18 +	hgext.tex \
   31.19 +	hook.tex \
   31.20 +	intro.tex \
   31.21 +	mq.tex \
   31.22 +	mq-collab.tex \
   31.23 +	mq-ref.tex \
   31.24 +	preface.tex \
   31.25 +	srcinstall.tex \
   31.26 +	template.tex \
   31.27 +	tour-basic.tex \
   31.28 +	tour-merge.tex \
   31.29 +	undo.tex
   31.30 +
   31.31 +image-sources := \
   31.32 +	feature-branches.dot \
   31.33 +	filelog.svg \
   31.34 +	kdiff3.png \
   31.35 +	metadata.svg \
   31.36 +	mq-stack.svg \
   31.37 +	note.png \
   31.38 +	revlog.svg \
   31.39 +	snapshot.svg \
   31.40 +	tour-history.svg \
   31.41 +	tour-merge-conflict.svg \
   31.42 +	tour-merge-merge.svg \
   31.43 +	tour-merge-pull.svg \
   31.44 +	tour-merge-sep-repos.svg \
   31.45 +	undo-manual.dot \
   31.46 +	undo-manual-merge.dot \
   31.47 +	undo-non-tip.dot \
   31.48 +	undo-simple.dot \
   31.49 +	wdir.svg \
   31.50 +	wdir-after-commit.svg \
   31.51 +	wdir-branch.svg \
   31.52 +	wdir-merge.svg \
   31.53 +	wdir-pre-branch.svg
   31.54 +
   31.55 +image-dot := $(filter %.dot,$(image-sources))
   31.56 +image-svg := $(filter %.svg,$(image-sources))
   31.57 +image-png := $(filter %.png,$(image-sources))
   31.58 +
   31.59 +image-pdf := $(image-dot:%.dot=%.pdf) $(image-svg:%.svg=%.pdf) $(image-png)
   31.60 +image-html := $(image-dot:%.dot=%.png) $(image-svg:%.svg=%.png) $(image-png)
   31.61 +
   31.62 +example-sources := \
   31.63 +	backout \
   31.64 +	bisect \
   31.65 +	branching \
   31.66 +	branch-named \
   31.67 +	branch-repo \
   31.68 +	cmdref \
   31.69 +	daily.copy \
   31.70 +	daily.files \
   31.71 +	daily.rename \
   31.72 +	daily.revert \
   31.73 +	extdiff \
   31.74 +	filenames \
   31.75 +	hook.msglen \
   31.76 +	hook.simple \
   31.77 +	hook.ws \
   31.78 +	issue29 \
   31.79 +	mq.guards \
   31.80 +	mq.qinit-help \
   31.81 +	mq.dodiff \
   31.82 +	mq.id \
   31.83 +	mq.tarball \
   31.84 +	mq.tools \
   31.85 +	mq.tutorial \
   31.86 +	rename.divergent \
   31.87 +	rollback \
   31.88 +	tag \
   31.89 +	template.simple \
   31.90 +	template.svnstyle \
   31.91 +	tour \
   31.92 +	tour-merge-conflict
   31.93 +
   31.94 +example-prereqs := \
   31.95 +	/usr/bin/merge
   31.96 +
   31.97 +dist-sources := \
   31.98 +	../html/hgicon.png \
   31.99 +	../html/index.html.var \
  31.100 +	../html/index.en.html \
  31.101 +	../html/index.es.html
  31.102 +
  31.103 +latex-options = \
  31.104 +	-interaction batchmode \
  31.105 +	-output-directory $(dir $(1)) \
  31.106 +	-jobname $(basename $(notdir $(1)))
  31.107 +
  31.108 +hg = $(shell which hg)
  31.109 +
  31.110 +hg-id = $(shell hg parents --template '{node|short}, fechado {date|isodate},\n')
  31.111 +
  31.112 +hg-version = $(shell hg version -q | \
  31.113 +		     sed 's,.*(versión \(unknown\|[a-f0-9+]*\)),\1,')
  31.114 +
  31.115 +all: pdf html
  31.116 +
  31.117 +pdf: pdf/hgbook.pdf
  31.118 +
  31.119 +define pdf
  31.120 +	mkdir -p $(dir $@)
  31.121 +	TEXINPUTS=$(dir $<): pdflatex $(call latex-options,$@) $< || (rm -f $@; exit 1)
  31.122 +	cp 99book.bib $(dir $@)
  31.123 +	cd $(dir $@) && bibtex $(basename $(notdir $@))
  31.124 +	cd $(dir $@) && makeindex $(basename $(notdir $@))
  31.125 +	TEXINPUTS=$(dir $<): pdflatex $(call latex-options,$@) $< || (rm -f $@; exit 1)
  31.126 +	TEXINPUTS=$(dir $<): pdflatex $(call latex-options,$@) $< || (rm -f $@; exit 1)
  31.127 +	if grep 'Reference.*undefined' $(@:.pdf=.log); then exit 1; fi
  31.128 +endef
  31.129 +
  31.130 +pdf/hgbook.pdf: $(sources) examples $(image-pdf)
  31.131 +	$(call pdf)
  31.132 +
  31.133 +html: onepage split
  31.134 +
  31.135 +onepage: $(htlatex) html/onepage/hgbook.html html/onepage/hgbook.css $(image-html:%=html/onepage/%)
  31.136 +
  31.137 +html/onepage/%: %
  31.138 +	cp $< $@
  31.139 +
  31.140 +split: $(htlatex) html/split/hgbook.html html/split/hgbook.css $(image-html:%=html/split/%)
  31.141 +
  31.142 +html/split/%: %
  31.143 +	cp $< $@
  31.144 +
  31.145 +# This is a horrible hack to work around the fact that the htlatex
  31.146 +# command in tex4ht is itself a horrible hack.  I really don't want to
  31.147 +# include verbatim the big wad of TeX that is repeated in that script,
  31.148 +# but I've given up and run a hacked copy as htlatex.book here.
  31.149 +
  31.150 +define htlatex
  31.151 +	mkdir -p $(dir $(1))
  31.152 +	cp 99book.bib $(dir $(1))
  31.153 +	TEXINPUTS=$(dir $(2)): ./htlatex.book $(2) "bookhtml,html4-uni,$(3)" " -cunihtf -utf8" "$(dir $(1))" "$(call latex-options,$(1))" || (rm -f $(1); exit 1)
  31.154 +	cd $(dir $(1)) && tex4ht -f/$(basename $(notdir $(1))) -cvalidate -cunihtf
  31.155 +	cd $(dir $(1)) && t4ht -f/$(basename $(notdir $(1)))
  31.156 +	./fixhtml.py $(dir $(1))/*.html
  31.157 +	rm $(dir $(1))/hgbook.css
  31.158 +endef
  31.159 +
  31.160 +html/onepage/hgbook.html: $(sources) examples $(image-html) bookhtml.cfg
  31.161 +	$(call htlatex,$@,$<)
  31.162 +
  31.163 +html/split/hgbook.html: $(sources) examples bookhtml.cfg
  31.164 +	$(call htlatex,$@,$<,2)
  31.165 +
  31.166 +# Produce 90dpi PNGs for the web.
  31.167 +
  31.168 +%.png: %.svg fixsvg
  31.169 +	./fixsvg $<
  31.170 +	inkscape -D -e $@ $<-tmp.svg
  31.171 +	rm $<-tmp.svg
  31.172 +
  31.173 +%.svg: %.dot
  31.174 +	dot -Tsvg -o $@ $<
  31.175 +
  31.176 +# Produce eps & pdf for the pdf
  31.177 +
  31.178 +%.pdf: %.eps
  31.179 +	epstopdf $<
  31.180 +
  31.181 +%.eps: %.svg
  31.182 +	./fixsvg $<
  31.183 +	inkscape -E $@ $<-tmp.svg
  31.184 +	rm $<-tmp.svg
  31.185 +
  31.186 +%.eps: %.dot
  31.187 +	dot -Tps -o $@ $<
  31.188 +
  31.189 +examples: $(example-prereqs) examples/.run
  31.190 +
  31.191 +examples/.run: $(example-sources:%=examples/%.run)
  31.192 +	touch examples/.run
  31.193 +
  31.194 +examples/%.run: examples/% examples/run-example
  31.195 +	cd examples && ./run-example $(notdir $<)
  31.196 +
  31.197 +changelog := $(wildcard ../.hg/store/00changelog.[id])
  31.198 +ifeq ($(changelog),)
  31.199 +changelog := $(wildcard ../.hg/00changelog.[id])
  31.200 +endif
  31.201 +
  31.202 +build_id.tex: $(changelog)
  31.203 +	echo -n '$(hg-id)' > build_id.tex
  31.204 +
  31.205 +hg_id.tex: $(hg)
  31.206 +	echo -n '$(hg-version)' > hg_id.tex
  31.207 +
  31.208 +clean:
  31.209 +	rm -rf dist html pdf \
  31.210 +		$(image-dot:%.dot=%.pdf) \
  31.211 +		$(image-dot:%.dot=%.png) \
  31.212 +		$(image-svg:%.svg=%.pdf) \
  31.213 +		$(image-svg:%.svg=%.png) \
  31.214 +		examples/*.{lxo,run} examples/.run build_id.tex hg_id.tex
  31.215 +
  31.216 +install: pdf split $(dist-sources) 
  31.217 +	rm -rf dist
  31.218 +	mkdir -p dist
  31.219 +	cp pdf/hgbook.pdf dist
  31.220 +	cp html/split/*.{css,html,png} dist
  31.221 +	cp html/onepage/hgbook.html dist/onepage.html
  31.222 +	ln -s index.es.html dist/index.html
  31.223 +	cp $(dist-sources) dist
  31.224 +
  31.225 +rsync: install
  31.226 +	rsync -avz --delete dist/ ikks@sulaco.devnull.li:public_html/hgbook/

    32.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    32.2 +++ b/es/bookhtml.cfg	Thu Jan 29 22:00:07 2009 -0800
    32.3 @@ -0,0 +1,1 @@
    32.4 +../en/bookhtml.cfg
    32.5 \ No newline at end of file

    33.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    33.2 +++ b/es/branch.tex	Thu Jan 29 22:00:07 2009 -0800
    33.3 @@ -0,0 +1,412 @@
    33.4 +%% vim: tw=70 encoding=utf8
    33.5 +\chapter{Administración de versiones y desarrollo ramificado}
    33.6 +\label{chap:branch}
    33.7 +
    33.8 +Mercurial ofrece varios mecanismos que le permiten administrar un
    33.9 +proyecto que avanza en múltiples frentes simultáneamente. Para
   33.10 +entender estos mecanismos, demos un vistazo a la estructura usual de
   33.11 +un proyecto de software.
   33.12 +
   33.13 +Muchos proyectos de software liberan una versión ``mayor'' que contiene
   33.14 +nuevas características substanciales.  En paralelo, pueden liberar
   33.15 +versiones ``menores''.   Usualmente éstas son idénticas a las
   33.16 +versiones mayores en las cuales están basadas, pero con arreglos para
   33.17 +algunos fallos.
   33.18 +
   33.19 +En este capítulo, comenzaremos hablando de cómo mantener registro de
   33.20 +etapas del proyecto como las liberaciones de una
   33.21 +versión. Continuaremos hablando del flujo de trabajo entre las
   33.22 +diferentes fases de un proyecto, y cómo puede ayudar Mercurial a
   33.23 +aislar y administrar tal trabajo.
   33.24 +
   33.25 +\section{Dar un nombre persistente a una revisión}
   33.26 +
   33.27 +Cuando usted decide otorgar a una revisión el nombre particular de una
   33.28 +``versión'', es buena idea grabar la identidad de tal revisión.
   33.29 +Esto le permitirá reproducir dicha versión en una fecha posterior,
   33.30 +para cualquiera que sea el 
   33.31 +propósito que se tenga en ese momento (reproducir un fallo, portar
   33.32 +a una nueva plataforma, etc).
   33.33 +\interaction{tag.init}
   33.34 +
   33.35 +Mercurial le permite dar un nombre permanente a cualquier revisión
   33.36 +usando la orden \hgcmd{tag}.  Sin causa de sorpresa, esos nombres se llaman
   33.37 +``tags'' (etiquetas).
   33.38 +\interaction{tag.tag}
   33.39 +
   33.40 +Una etiqueta no es más que un ``nombre simbólico'' para una revisión.  Las
   33.41 +etiquetas existen únicamente para su conveniencia, brindándole una forma
   33.42 +permanente y sencilla de referirse a una revisión; Mercurial no
   33.43 +interpreta de ninguna manera los nombres de las etiquetas que usted use.
   33.44 +Mercurial tampoco impone restricción alguna al nombre de una etiqueta, más
   33.45 +allá de lo necesario para asegurar que una etiqueta pueda procesarse sin
   33.46 +ambigüedades. El nombre de una etiqueta no puede tener ninguno de los
   33.47 +siguientes caracteres:
   33.48 +\begin{itemize}
   33.49 +\item Dos puntos (ASCII 58, ``\texttt{:}'')
   33.50 +\item Retorno de carro (return) (ASCII 13, ``\Verb+\r+'')
   33.51 +\item Nueva línea (ASCII 10, ``\Verb+\n+'')
   33.52 +\end{itemize}
   33.53 +
   33.54 +Puede usar la orden \hgcmd{tags} para ver las etiquetas presentes en
   33.55 +su repositorio. Al desplegarse, cada revisión marcada se identifica
   33.56 +primero con su nombre, después con el número de revisión y finalmente con
   33.57 +un hash único de la revisión.
   33.58 +\interaction{tag.tags}
   33.59 +Note que \texttt{tip} aparece en en listado generado por \hgcmd{tags}. La etiqueta
   33.60 +\texttt{tip} es una etiqueta ``flotante'' especial, que identifica siempre
   33.61 +la revisión más reciente en el repositorio.
   33.62 +
   33.63 +Al desplegar la orden \hgcmd{tags}, las etiquetas se listan en orden
   33.64 +inverso, por número de revisión. Lo que significa usualmente que las
   33.65 +etiquetas más recientes se listan antes que las más antiguas. También
   33.66 +significa que la etiqueta \texttt{tip} siempre aparecerá como primera
   33.67 +etiqueta listada al desplegar la orden \hgcmd{tags}.
   33.68 +
   33.69 +Cuando usted ejecuta \hgcmd{log}, si se muestra una revisión que tenga 
   33.70 +etiquetas asociadas a ella, se imprimirán tales etiquetas.
   33.71 +\interaction{tag.log}
   33.72 +
   33.73 +Siempre que requiera indicar un~ID de revisión a una orden de
   33.74 +Mercurial, aceptará un nombre de etiqueta en su lugar.  Internamente,
   33.75 +Mercurial traducirá su nombre de etiqueta en el~ID de revisión
   33.76 +correspondiente, y lo usará.
   33.77 +\interaction{tag.log.v1.0}
   33.78 +
   33.79 +No hay límites en la cantidad de etiquetas por repositorio, o la cantidad
   33.80 +de etiquetas que una misma revisión pueda tener. Siendo prácticos, no es
   33.81 +muy buena idea tener ``demasiadas'' (la cantidad variará de un
   33.82 +proyecto a otro), debido a que la intención es ayudarle a encontrar
   33.83 +revisiones. Si tiene demasiadas etiquetas, la facilidad de usarlas
   33.84 +para identificar revisiones disminuirá rápidamente.
   33.85 +
   33.86 +Por ejemplo, si su proyecto tiene etapas (milestones) frecuentes, de pocos
   33.87 +días, es perfectamente razonable asignarle una etiqueta a cada una de
   33.88 +ellas. Pero si tiene un sistema de construcción automática de binarios
   33.89 +que asegura que cada revisión puede generarse limpiamente, estaría
   33.90 +introduciendo mucho ruido si se usara una etiqueta para cada generación
   33.91 +exitosa. Más bien, podría usar tags para generaciones fallidas
   33.92 +(\textexclamdown en
   33.93 +caso de que estas sean raras!), o simplemente evitar las etiquetas para
   33.94 +llevar cuenta de la posibilidad de generación de binarios.
   33.95 +
   33.96 +
   33.97 +Si quiere eliminar una etiqueta que no desea, use
   33.98 +\hgcmdargs{tag}{--remove}.  
   33.99 +\interaction{tag.remove}
  33.100 +También puede modificar una etiqueta en cualquier momento, para que
  33.101 +identifique una revisión distinta, simplemente usando una nueva orden
  33.102 +\hgcmd{tag}. Deberá usar la opción \hgopt{tag}{-f} para indicarle a
  33.103 +Mercurial que \emph{realmente} desea actualizar la etiqueta.
  33.104 +\interaction{tag.replace}
  33.105 +De todas maneras habrá un registro permanente de la antigua identidad
  33.106 +de la etiqueta, pero Mercurial no la usará. Por lo tanto no hay
  33.107 +problema al marcar con una etiqueta una revisión incorrecta; lo único
  33.108 +que debe hacer es mover la etiqueta hacia la revisión correcta tan
  33.109 +pronto como localice el error.
  33.110 +
  33.111 +Mercurial almacena las etiquetas en un fichero controlado por revisiones en
  33.112 +su repositorio. Si ha creado etiquetas, las encontrará en un fichero
  33.113 +llamado \sfilename{.hgtags}.  Cuando invoca la orden \hgcmd{tag},
  33.114 +Mercurial modifica este fichero, y hace la consignación del cambio al
  33.115 +mismo automáticamente.  Esto significa que cada vez que ejecuta
  33.116 +\hgcmd{tag}, verá un conjunto de cambios correspondiente en la salida
  33.117 +de \hgcmd{log}.
  33.118 +\interaction{tag.tip}
  33.119 +
  33.120 +\subsection{Manejo de conflictos entre etiquetas durante una fusión}
  33.121 +
  33.122 +Usualmente no tendrá que preocuparse por el fichero \sfilename{.hgtags},
  33.123 +pero a veces hace su aparición durante una fusión. El formato del
  33.124 +fichero es sencillo: Consiste de una serie de líneas. Cada línea
  33.125 +comienza con un hash de conjunto de cambios, seguido por un espacio,
  33.126 +seguido por el nombre de una etiqueta.
  33.127 +
  33.128 +Si está resolviendo un conflicto en el fichero \sfilename{.hgtags}
  33.129 +durante una fusión, hay un detalle para tener en cuenta al modificar
  33.130 +el fichero \sfilename{.hgtags}:
  33.131 +cuando Mercurial procesa las etiquetas en el repositorio, \emph{nunca}
  33.132 +lee la copia de trabajo del fichero \sfilename{.hgtags}.  En cambio,
  33.133 +lee la versión \emph{consignada más reciente} del fichero.
  33.134 +
  33.135 +Una consecuencia desafortunada de este diseño es que usted no puede
  33.136 +verificar que su fichero \sfilename{.hgtags} fusionado sea correcto hasta
  33.137 +\emph{después} de haber consignado un cambio. Así que si se
  33.138 +encuentra resolviendo un conflicto en \sfilename{.hgtags} durante una
  33.139 +fusión, asegúrese de ejecutar la orden \hgcmd{tags} después de
  33.140 +consignar. Si encuentra un error en el fichero \sfilename{.hgtags}, 
  33.141 +la orden reportará el lugar del error, que podrá arreglar y después
  33.142 +consignar. Posteriormente ejecute de nuevo la orden \hgcmd{tags} para
  33.143 +asegurarse de que su arreglo fue aplicado correctamente .
  33.144 +
  33.145 +\subsection{Etiquetas y clonado}
  33.146 +
  33.147 +Puede haber notado que la orden \hgcmd{clone} tiene la opción
  33.148 +\hgopt{clone}{-r} que le permite clonar una copia exacta del
  33.149 +repositorio hasta un conjunto de cambios específico. El nuevo clon no
  33.150 +tendrá historial posterior a la revisión que usted haya
  33.151 +especificado. Esto tiene una interacción con etiquetas que puede
  33.152 +sorprender a los desprevenidos.
  33.153 +
  33.154 +Recuerde que una etiqueta se almacena como una revisión al fichero
  33.155 +\sfilename{.hgtags}, así que cuando usted crea una etiqueta, el
  33.156 +conjunto de cambios en el cual ésta se almacena necesariamente se
  33.157 +refiere a un conjunto de cambios anterior. Cuando ejecuta
  33.158 +\hgcmdargs{clone}{-r foo} para clonar un repositorio hasta la etiqueta
  33.159 +\texttt{foo}, el nuevo clon \emph{no contendrá el historial que creo
  33.160 +la etiqueta} que usó para clonar el repositorio. El resultado es que tendrá
  33.161 +exactamente el subconjunto correcto del historial del proyecto en el
  33.162 +nuevo repositorio, pero, \emph{no} la etiqueta que podría haber esperado.
  33.163 +
  33.164 +\subsection{Cuando las etiquetas permanentes son demasiado}
  33.165 +
  33.166 +Dado que las etiquetas de Mercurial están controladas por revisiones y se
  33.167 +llevan en el historial del proyecto, todas las personas involucradas
  33.168 +verán las etiquetas que usted haya creado. El hecho de dar nombres a las
  33.169 +revisiones tiene usos más allá que simplemente hacer notar que la
  33.170 +revisión \texttt{4237e45506ee} es realmente \texttt{v2.0.2}.  Si está
  33.171 +tratando de encontrar un fallo sutil, posiblemente desearía colocar una 
  33.172 +etiqueta recordándole algo como ``Ana vio los síntomas en esta revisión''.
  33.173 +
  33.174 +Para estos casos, lo que usted posiblemente desearía serían etiquetas
  33.175 +\emph{locales}. Puede crear una etiqueta local con la opción~\hgopt{tag}{-l}
  33.176 +de la orden \hgcmd{tag}.  Esto guardará la etiqueta en un fichero llamado
  33.177 +\sfilename{.hg/localtags}.  A diferencia de \sfilename{.hgtags},
  33.178 +\sfilename{.hg/localtags} no está controlado por revisiones.
  33.179 +Cualquier etiqueta que usted cree usando \hgopt{tag}{-l} se mantendrá
  33.180 +local al repositorio en el que esté trabajando en ese momento.
  33.181 +
  33.182 +\section{El flujo de cambios---El gran cuadro vs. el pequeño}
  33.183 +
  33.184 +Retomando lo mencionado en el comienzo de un capítulo, pensemos en el
  33.185 +hecho de que un proyecto tiene muchas piezas concurrentes de trabajo
  33.186 +en desarrollo al mismo tiempo.
  33.187 +
  33.188 +Puede haber prisa por una nueva versión ``principal''; una nueva
  33.189 +versión con un arreglo de fallo a la última versión; y una versión de
  33.190 +``mantenimiento correctivo'' a una versión antigua que ha entrado en
  33.191 +modo de mantenimiento.
  33.192 +
  33.193 +Usualmente la gente se refiere a esas direcciones
  33.194 +concurrentes de desarrollo como ``ramas''.  Sin embargo, ya hemos visto que
  33.195 +en varias ocasiones Mercurial trata a \emph{todo el historial} como
  33.196 +una serie de ramas y fusiones.  Realmente lo que tenemos aquí es dos
  33.197 +ideas que se relacionan periféricamente, pero que en esencia comparten
  33.198 +un nombre.
  33.199 +\begin{itemize}
  33.200 +\item ``El gran cuadro'' Las ramas representan un barrido de la
  33.201 +  evolución del proyecto; la gente les da nombres y hablan acerca de
  33.202 +  ellas en sus conversaciones.
  33.203 +\item ``El cuadro pequeño'' Las ramas son artefactos de las
  33.204 +  actividades diarias de desarrollar y fusionar cambios. Exponen la
  33.205 +  narrativa de cómo se desarrolló el código.
  33.206 +\end{itemize}
  33.207 +
  33.208 +\section{Administrar ramas en repositorios estilo gran cuadro}
  33.209 +
  33.210 +En Mercurial la forma más sencilla de aislar una rama del ``gran
  33.211 +cuadro'' es a través de un repositorio dedicado.  Si cuenta con un
  33.212 +repositorio compartido existente ---llamémoslo
  33.213 +\texttt{myproject}---que alcanzó la etapa ``1.0'', puede comenzar a
  33.214 +prepararse para versiones de mantenimiento futuras a partir de la
  33.215 +versión~1.0 marcando con una etiqueta la revisión con la cual preparó la versión~1.0.
  33.216 +\interaction{branch-repo.tag}
  33.217 +Ahora puede clonar un repositorio compartido nuevo
  33.218 +\texttt{myproject-1.0.1} con tal etiqueta.
  33.219 +\interaction{branch-repo.clone}
  33.220 +
  33.221 +Posteriormente, si alguien necesita trabajar en la reparación de un
  33.222 +fallo debería dirigirse a la liberación de versión~1.0.1 que viene en
  33.223 +camino, ellos clonarían el repositorio \texttt{myproject-1.0.1},
  33.224 +harían sus cambios y los empujarían de vuelta.
  33.225 +\interaction{branch-repo.bugfix}
  33.226 +Mientras tanto, el desarrollo para la siguiente versión mayor puede
  33.227 +continuar aislado e incólume, en el repositorio \texttt{myproject}.
  33.228 +\interaction{branch-repo.new}
  33.229 +
  33.230 +\section{No repita trabajo: fusión entre ramas}
  33.231 +
  33.232 +En muchos casos, cuando tiene un fallo para arreglar en una rama de
  33.233 +mantenimiento, es muy probable que el fallo también esté en la rama
  33.234 +principal (y posiblemente en otras ramas de mantenimiento
  33.235 +también). Solamente un desarrollador extraño desearía corregir el
  33.236 +mismo fallo muchas veces, por tanto, veremos varias alternativas con
  33.237 +las que Mercurial puede ayudarle a administrar tales arreglos de fallo
  33.238 +sin duplicar su trabajo.
  33.239 +
  33.240 +En el caso más sencillo, basta con jalar los cambios de la rama de
  33.241 +mantenimiento a la rama objetivo en su clon local.
  33.242 +\interaction{branch-repo.pull}
  33.243 +A continuación deberá mezclar las cabezas de las dos ramas, y empujar
  33.244 +de nuevo a la rama principal.
  33.245 +\interaction{branch-repo.merge}
  33.246 +
  33.247 +\section{Nombrar ramas dentro de un repositorio}
  33.248 +
  33.249 +La aproximación correcta en casi todas las oportunidades es aislar las
  33.250 +ramas en los repositorios.  Es fácil de entender gracias a su
  33.251 +simplicidad; y es difícil cometer errores. Hay una relación uno a uno
  33.252 +entre las ramas y los directorios con los que está trabajando en su
  33.253 +sistema. Esto le permite usar emplear herramientas usuales (que no son
  33.254 +conscientes de Mercurial) para trabajar con los ficheros dentro de una
  33.255 +rama/repositorio.
  33.256 +
  33.257 +Si se encuentra más en la categoría ``usuario diestro'' (\emph{y} sus
  33.258 +colaboradores también), puede considerar otra alternativa para
  33.259 +administrar las ramas. He mencionado con anterioridad la distinción a
  33.260 +nivel humano entre las ramas estilo ``cuadro pequeño'' y ``gran
  33.261 +cuadro''.  Mientras que Mercurial trabaja con muchas ramas del estilo
  33.262 +``cuadro pequeño'' en el repositorio todo el tiempo (por ejemplo cuando
  33.263 +usted jala cambios, pero antes de fusionarlos), \emph{también} puede
  33.264 +trabajar con varias ramas del ``cuadro grande''.
  33.265 +
  33.266 +El truco para trabajar de esta forma en Mercurial se logra gracias a
  33.267 +que puede asignar un \emph{nombre} persistente a una rama.  Siempre
  33.268 +existe una rama llamada \texttt{default}.  Incluso antes de que
  33.269 +empiece a nombrar ramas por su cuenta, puede encontrar indicios de la
  33.270 +rama \texttt{default} si los busca.
  33.271 +
  33.272 +Por ejemplo, cuando invoca la orden \hgcmd{commit}, y se lanza su
  33.273 +editor para introducir el mensaje de la consignación, busque la línea
  33.274 +que contiene el texto ``\texttt{HG: branch default}'' al final. Le
  33.275 +está indicando que su consignación ocurrirá en la rama llamada 
  33.276 +\texttt{default}.
  33.277 +
  33.278 +Use la orden \hgcmd{branches} para empezar a trabajar con ramas
  33.279 +nombradas. Esta orden mostrará las ramas presentes en su repositorio,
  33.280 +indicándole qué conjunto de cambios es la punta de cada una.
  33.281 +\interaction{branch-named.branches}
  33.282 +Dado que todavía no ha creado ramas nombradas, la única que verá será
  33.283 +\texttt{default}.
  33.284 +
  33.285 +Para hallar cuál es la rama ``actual'', invoque la orden
  33.286 +\hgcmd{branch}, sin argumento alguno. Le informará en qué rama se
  33.287 +encuentra el padre del conjunto de cambios actual.
  33.288 +\interaction{branch-named.branch}
  33.289 +
  33.290 +Para crear una nueva rama, invoque la orden \hgcmd{branch} de
  33.291 +nuevo. En esta oportunidad, ofrezca un argumento: el nombre de la rama
  33.292 +que desea crear.
  33.293 +\interaction{branch-named.create}
  33.294 +
  33.295 +Después de crear la rama, usted podría desear ver el efecto que tuvo
  33.296 +la orden \hgcmd{branch}.  ¿Qué reportan las ordenes \hgcmd{status} y
  33.297 +\hgcmd{tip}?
  33.298 +\interaction{branch-named.status}
  33.299 +Nada cambia en el directorio actual, y no se ha añadido nada al
  33.300 +historial. Esto sugiere que al ejecutar la orden \hgcmd{branch} no hay
  33.301 +un efecto permanente; solamente le indica a que nombre de rama usará
  33.302 +la \emph{próxima} vez que consigne un conjunto de cambios.
  33.303 +
  33.304 +Cuando consigna un cambio, Mercurial almacena el nombre de la rama en
  33.305 +la cual consignó.  Una vez que haya cambiado de la rama \texttt{default}
  33.306 +y haya consignado, verá que el nombre de la nueva rama se mostrará
  33.307 +cuando use la orden \hgcmd{log}, \hgcmd{tip}, y otras órdenes que
  33.308 +desplieguen la misma clase de información.
  33.309 +\interaction{branch-named.commit}
  33.310 +Las órdenes del tipo \hgcmd{log} imprimirán el nombre de la rama de
  33.311 +cualquier conjunto de cambios que no esté en la rama
  33.312 +\texttt{default}. Como resultado, si nunca usa ramas nombradas, nunca
  33.313 +verá esta información.
  33.314 +
  33.315 +Una vez que haya nombrado una rama y consignado un cambio con ese
  33.316 +nombre, todas las consignaciones subsecuentes que desciendan de ese
  33.317 +cambio heredarán el mismo nombre de rama. Puede cambiar el nombre de
  33.318 +una rama en cualquier momento con la orden \hgcmd{branch}.  
  33.319 +\interaction{branch-named.rebranch}
  33.320 +Esto es algo que no hará muy seguido en la práctica, debido que los
  33.321 +nombres de las ramas tienden a tener vidas largas.  (Esto no es una
  33.322 +regla, solamente una observación.)
  33.323 +
  33.324 +\section{Tratamiento de varias ramas nombradas en un repositorio}
  33.325 +
  33.326 +Si tiene más de una rama nombrada en un repositorio, Mercurial
  33.327 +recordará la rama en la cual está su directorio de trabajo cuando
  33.328 +invoque una orden como \hgcmd{update} o \hgcmdargs{pull}{-u}.  Se
  33.329 +actualizará su directorio de trabajo actual a la punta de esta rama, sin
  33.330 +importar cuál sea la punta ``a lo largo del repositorio''.  Para
  33.331 +actualizar a una revisión que está en una rama con distinto nombre,
  33.332 +puede necesitar la opción \hgopt{update}{-C} de \hgcmd{update}.
  33.333 +
  33.334 +Este comportamiento puede ser sutil, así que veámoslo en acción.  Primero,
  33.335 +recordemos en qué rama estamos trabajando, y qué ramas están en
  33.336 +nuestro repositorio.
  33.337 +\interaction{branch-named.parents}
  33.338 +Estamos en la rama \texttt{bar}, pero existe otra rama más antigua
  33.339 +llamada \hgcmd{foo}.
  33.340 +
  33.341 +Podemos hacer \hgcmd{update} entre los tipos de las ramas \texttt{foo}
  33.342 +y \texttt{bar} sin necesidad de usar la opción \hgopt{update}{-C},
  33.343 +puesto que esto solamente implica ir linealmente hacia adelante y
  33.344 +atrás en nuestro historial de cambios.
  33.345 +\interaction{branch-named.update-switchy}
  33.346 +
  33.347 +Si volvemos a la rama \texttt{foo} e invocamos la orden \hgcmd{update},
  33.348 +nos mantendrá en \texttt{foo}, sin movernos a la punta de \texttt{bar}.
  33.349 +\interaction{branch-named.update-nothing}
  33.350 +
  33.351 +Al consignar un cambio a la rama \texttt{foo} se introducirá una nueva
  33.352 +cabeza.
  33.353 +\interaction{branch-named.foo-commit}
  33.354 +
  33.355 +\section{Nombres de ramas y fusiones}
  33.356 +
  33.357 +Posiblemente ha notado que las fusiones en Mercurial no son simétricas.
  33.358 +Supongamos que su repositorio tiene dos cabezas, 17 y 23.  Si yo invoco
  33.359 +\hgcmd{update} a 17 y aplico \hgcmd{merge} a 23, Mercurial almacena 17
  33.360 +como el primer padre de la fusión, y 23 como el segundo. Mientras que
  33.361 +si hago \hgcmd{update} a 23 y después aplico \hgcmd{merge} con 17,
  33.362 +grabará a 23 como el primer padre, y 17 como el segundo.
  33.363 +
  33.364 +Esto afecta el cómo elige Mercurial el nombre de la rama cuando usted
  33.365 +hace la fusión.  Después de una fusión, Mercurial mantendrá el nombre de la
  33.366 +rama del primer padre cuando consigne el resultado de la fusión.  Si
  33.367 +el primer nombre de su padre es \texttt{foo}, y fusiona con
  33.368 +\texttt{bar}, el nombre de la rama continuará siendo \texttt{foo}
  33.369 +después de fusionar.
  33.370 +
  33.371 +No es inusual que un repositorio contenga varias cabezas, cada una con
  33.372 +el mismo nombre de rama.  Digamos que estoy trabajando en la rama
  33.373 +\texttt{foo}, y usted también.  Consignamos cambios distintos; yo jalo
  33.374 +sus cambios; Ahora tengo dos cabezas, cada una afirmando estar en la
  33.375 +rama \texttt{foo}.  El resultado de una fusión será una única cabeza
  33.376 +en la rama \texttt{foo} como usted esperaría.
  33.377 +
  33.378 +Pero si estoy trabajando en la rama \texttt{bar}, y fusiono el trabajo
  33.379 +de la rama \texttt{foo}, el resultado permanecerá en la rama
  33.380 +\texttt{bar}.
  33.381 +\interaction{branch-named.merge}
  33.382 +
  33.383 +En un ejemplo más concreto, si yo estoy trabajando en la rama
  33.384 +\texttt{bleeding-edge}, y deseo traer los arreglos más recientes de la
  33.385 +rama \texttt{estable}, Mercurial elegirá el nombre de rama ``correcto''
  33.386 +(\texttt{bleeding-edge}) cuando yo jale una fusión desde \texttt{estable}.
  33.387 +
  33.388 +\section{Normalmente es útil nombrar ramas}
  33.389 +
  33.390 +No debería considerar que las ramas nombradas son aplicables
  33.391 +únicamente en situaciones con muchas ramas de larga vida cohabitando
  33.392 +en un mismo repositorio.  Son muy útiles incluso en los casos de
  33.393 +una rama por repositorio.
  33.394 +
  33.395 +En el caso más sencillo, dar un nombre a cada rama ofrece un registro
  33.396 +permanente acerca de en qué conjunto de cambios se generó la rama.
  33.397 +Esto le ofrece más contexto cuando esté tratando de seguir el
  33.398 +historial de un proyecto ramificado de larga vida.
  33.399 +
  33.400 +Si está trabajando con repositorios compartidos, puede configurar el gancho
  33.401 +\hook{pretxnchangegroup} para que cada uno bloquee los cambios con
  33.402 +nombres de rama ``incorrectos'' que están por adicionarse.  Este
  33.403 +provee una defensa sencilla, pero efectiva, para evitar que la gente
  33.404 +publique accidentalmente cambios de una rama ``super nueva'' a la rama
  33.405 +``estable''.  Tal gancho podría verse de la siguiente forma dentro de
  33.406 +un repositorio compartido de \hgrc.
  33.407 +\begin{codesample2}
  33.408 +  [hooks]
  33.409 +  pretxnchangegroup.branch = hg heads --template '{branches} ' | grep mybranch
  33.410 +\end{codesample2}
  33.411 +
  33.412 +%%% Local Variables: 
  33.413 +%%% mode: latex
  33.414 +%%% TeX-master: "00book"
  33.415 +%%% End: 

    34.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    34.2 +++ b/es/cmdref.py	Thu Jan 29 22:00:07 2009 -0800
    34.3 @@ -0,0 +1,1 @@
    34.4 +../en/cmdref.py
    34.5 \ No newline at end of file

    35.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    35.2 +++ b/es/cmdref.tex	Thu Jan 29 22:00:07 2009 -0800
    35.3 @@ -0,0 +1,186 @@
    35.4 +\chapter{Referencia de Órdenes}
    35.5 +\label{cmdref}
    35.6 +
    35.7 +\cmdref{add}{Añade ficheros en la próxima consignación}
    35.8 +\optref{add}{I}{include}
    35.9 +\optref{add}{X}{exclude}
   35.10 +\optref{add}{n}{dry-run}
   35.11 +
   35.12 +\cmdref{diff}{imprime los cambios en el historial o el directorio actual}
   35.13 +
   35.14 +Mostrar las diferencias entre revisiones para ficheros especificados o
   35.15 +directorios, con el formato unificado diff.  Si desea ver una
   35.16 +descripción del formato unificado diff, ver la sección~\ref{sec:mq:patch}.
   35.17 +
   35.18 +De forma predeterminada, esta orden no imprime las diferencias para
   35.19 +los ficheros binarios que Mercurial esté siguiendo.  Para controlar
   35.20 +este comportamiento, vea las opciones \hgopt{diff}{-a} y
   35.21 +\hgopt{diff}{--git}.
   35.22 +
   35.23 +\subsection{Options}
   35.24 +
   35.25 +\loptref{diff}{nodates}
   35.26 +
   35.27 +Omite la fecha y hora cuando se muestran los encabezados de las
   35.28 +diferencias.
   35.29 +
   35.30 +\optref{diff}{B}{ignore-blank-lines}
   35.31 +
   35.32 +No imprime los cambios que solamente insertan o eliminan líneas en
   35.33 +blanco.  Una línea que contiene espacios en blanco no se considera
   35.34 +como una línea en blanco.
   35.35 +
   35.36 +\optref{diff}{I}{include}
   35.37 +
   35.38 +Incluye ficheros y directorios cuyos nombres coinciden con los
   35.39 +patrones elegidos.
   35.40 +
   35.41 +\optref{diff}{X}{exclude}
   35.42 +
   35.43 +Excluye los ficheros y directorios cuyos nombres coinciden con los
   35.44 +patrones elegidos.
   35.45 +
   35.46 +\optref{diff}{a}{text}
   35.47 +
   35.48 +Si no especifica esta opción, \hgcmd{diff} no mostrará las diferencias
   35.49 +de los ficheros que detecte como binarios.  Al especificar \hgopt{diff}{-a}
   35.50 +se forza a \hgcmd{diff} a tratar los ficheros como texto, y generar
   35.51 +diferencias para todos.
   35.52 +
   35.53 +Esta opción es útil para los ficherso que son ``texto en mayor
   35.54 +medida'' pero que tienen caracteres NUL.  Si lo usa en ficheros que
   35.55 +contienen muchos datos binarios, la salida será incomprensible.
   35.56 +
   35.57 +\optref{diff}{b}{ignore-space-change}
   35.58 +
   35.59 +No imprime si el único cambio que en la línea es la cantidad de
   35.60 +espacio en blanco.
   35.61 +
   35.62 +\optref{diff}{g}{git}
   35.63 +
   35.64 +Mostrar diferencias compatibles con \command{git}.  XXX reference a format
   35.65 +description.
   35.66 +
   35.67 +\optref{diff}{p}{show-function}
   35.68 +
   35.69 +Mostrar el nombre de la función que contiene el código en una porción
   35.70 +del encabzado usando una heurística simple.  Esta funcionalidad se
   35.71 +habilita de forma predeterminada, así que la opción \hgopt{diff}{-p}
   35.72 +no tiene efectos a menos que cambie el valor de
   35.73 +\rcitem{diff}{showfunc} en la configuración, como en el ejemplo
   35.74 +siguiente.
   35.75 +\interaction{cmdref.diff-p}
   35.76 +
   35.77 +\optref{diff}{r}{rev}
   35.78 +
   35.79 +Especifique una o más revisiones para comparar.  La orden \hgcmd{diff}
   35.80 +acepta hasta dos opciones \hgopt{diff}{-r} para especificar las
   35.81 +revisiones a comparar.
   35.82 +
   35.83 +\begin{enumerate}
   35.84 +\setcounter{enumi}{0}
   35.85 +\item Despliega las diferencias entre la revisión padre y del directorio
   35.86 +  de trabajo.
   35.87 +\item Despliega las diferencias entre el conjunto de cambios
   35.88 +  especificados y el directorio de trabajo.
   35.89 +\item Despliega las diferencias entre dos conjuntos de cambios
   35.90 +  especificados.
   35.91 +\end{enumerate}
   35.92 +
   35.93 +Puede especificar dos revisiones usando o bien sea las opciones
   35.94 +\hgopt{diff}{-r} o la notación de rango.  Por ejemplo, las dos
   35.95 +especificaciones de revisiones a continuación son equivalentes:
   35.96 +\begin{codesample2}
   35.97 +  hg diff -r 10 -r 20
   35.98 +  hg diff -r10:20
   35.99 +\end{codesample2}
  35.100 +
  35.101 +Cuando especifica dos revisiones, esto tiene significado para
  35.102 +Mercurial.  Esto significa que \hgcmdargs{diff}{-r10:20} producirá un
  35.103 +diff que transformará los ficheros desde los contenidos en la revisión
  35.104 +10 a los contenidos de la revisión 20, mientras que
  35.105 +\hgcmdargs{diff}{-r20:10} significa lo opuesto:  el diff que
  35.106 +transformaría los contenidos de los ficheros de la revisión 20 a los
  35.107 +contenidos de la revisión 10.  No puede invertir el orden de esta
  35.108 +forma si está haciendo un diff frente al directorio de trabajo.
  35.109 +
  35.110 +\optref{diff}{w}{ignore-all-space}
  35.111 +
  35.112 +\cmdref{version}{imprime la información de versión y derechos de reproducción}
  35.113 +
  35.114 +Esta orden despliega la versión de Mercurial que está usando, y su
  35.115 +nota de derechos de reproducción.  Hay cuatro clases de cadenas de
  35.116 +versión posibles:
  35.117 +\begin{itemize}
  35.118 +\item La cadena ``\texttt{unknown}''. Esta versión de Mercurial no fue
  35.119 +  construida en un repositorio de Mercurial, y no puede determinar su
  35.120 +  propia versión.
  35.121 +\item Una cadena numérica corta, tal como ``\texttt{1.1}''. Esta es
  35.122 +  una construcción de una versión de Mercurial que se identifica con
  35.123 +  una etiqueta específica en el repositorio en el cual fue
  35.124 +  armada (Esto no significa necesariamente que está ejecutando una
  35.125 +  versión oficial; alguien pudo haber añadido tal etiqueta a cualquier
  35.126 +  versión del repositorio en el cual armaron Mercurial).
  35.127 +\item Una cadena hexadecimal, tal como ``\texttt{875489e31abe}''.
  35.128 +  Esta es una construcción de una revisión dada de Mercurial.
  35.129 +\item Una cadena hexadecimal seguida por una fecha, tal como
  35.130 +  ``\texttt{875489e31abe+20070205}''.  Esta construcción de la
  35.131 +  revisión de Mercurial fue la construcción de un repositorio que tuvo
  35.132 +  cambios locales que no han sido consignados.
  35.133 +\end{itemize}
  35.134 +
  35.135 +\subsection{Consejos y trucos}
  35.136 +
  35.137 +\subsubsection{¿Por qué difieren los resultados de \hgcmd{diff} y
  35.138 +  \hgcmd{status}?}
  35.139 +\label{cmdref:diff-vs-status}
  35.140 +
  35.141 +Cuando ejecuta la orden \hgcmd{status}, verá una lista de ficheros
  35.142 +para los cuales Mercurial almacenará cambios la próxima vez que
  35.143 +consigne.  Si ejecuta la orden \hgcmd{diff}, verá que imprime
  35.144 +diferencias solamente para un \emph{subconjunto} de los ficheros que
  35.145 +\hgcmd{status} liste.  Hay dos posibles razones para este comportamiento:
  35.146 +
  35.147 +La primera es que \hgcmd{status} imprime cierta clase de
  35.148 +modificaciones que \hgcmd{diff} no despliega normalmente.  La orden
  35.149 +\hgcmd{diff} usualmente despliega diferencias unificadas, las cuales
  35.150 +no tienen la habilidad de representar algunos cambios que Mercurial
  35.151 +puede seguir.  Lo más notable es que las diferencias tradicionales no
  35.152 +pueden representar un cambio acerca de la ejecutabilidad de un
  35.153 +fichero, pero Mercurial sí almacena esta información.
  35.154 +
  35.155 +Si usa la opción \hgopt{diff}{--git} de \hgcmd{diff}, mostrará
  35.156 +diferencias compatibles con \command{git} que \emph{pueden} desplegar
  35.157 +esta información adicional.
  35.158 +
  35.159 +La segunda razón posible para que \hgcmd{diff} esté imprimiendo
  35.160 +diferencias para un subconjunto de ficheros de lo que muestra
  35.161 +\hgcmd{status} es que si usted le invoca sin argumento alguno,
  35.162 +\hgcmd{diff} imprime diferencias frente al primer padre del directorio
  35.163 +de trabajo.  Si ha ejecutado \hgcmd{merge} para fusionar dos conjuntos
  35.164 +de cambios, pero no ha consignado aún los resultados de la fusión,  su
  35.165 +directorio de trabajo tiene dos padres (use \hgcmd{parents} para
  35.166 +verlos).  Mientras que \hgcmd{status} imprime modificaciones relativas
  35.167 +a \emph{ambos} padres después de una fusión que no se ha consignado,
  35.168 +\hgcmd{diff} opera aún relativo solamente al primer padre.  Puede
  35.169 +lograr que imprima las diferencias relativas al segundo padre
  35.170 +especificando tal padre con la opción \hgopt{diff}{-r}.  No hay forma
  35.171 +de hacer que imprima las diferencias relativas a los dos padres.
  35.172 +
  35.173 +\subsubsection{Generar diferencias seguras en binarios}
  35.174 +
  35.175 +Si usa la opción \hgopt{diff}{-a} para forzar que Mercurial imprima
  35.176 +las diferencias de los ficheros que so o bien ``casi completamente
  35.177 +texto'' o contienen muchos datos binarios, tales diferencias no pueden
  35.178 +aplicarse subsecuentemente a la orden \hgcmd{import} de Mercurial o a
  35.179 +la orden \command{patch} del sistema.
  35.180 +
  35.181 +Si desea generar una diferencia de un fichero binario que es seguro
  35.182 +para usarlo como entrada a la orden \hgcmd{import}, use la opción
  35.183 +\hgcmd{diff}{--git} cuando genere el parche.  La orden \command{patch}
  35.184 +del sistema no puede tratar con parches binarios.
  35.185 +
  35.186 +%%% Local Variables: 
  35.187 +%%% mode: latex
  35.188 +%%% TeX-master: "00book"
  35.189 +%%% End: 

    36.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    36.2 +++ b/es/collab.tex	Thu Jan 29 22:00:07 2009 -0800
    36.3 @@ -0,0 +1,1059 @@
    36.4 +\chapter{Colaborar con otros}
    36.5 +\label{cha:collab}
    36.6 +
    36.7 +Debido a su naturaleza descentralizada, Mercurial no impone política
    36.8 +alguna de cómo deben trabajar los grupos de personas. Sin embargo, si
    36.9 +usted es nuevo al control distribuido de versiones, es bueno tener
   36.10 +herramientas y ejemplos a la mano al pensar en posibles modelos de
   36.11 +flujo de trabajo.
   36.12 +
   36.13 +\section{La interfaz web de Mercurial}
   36.14 +
   36.15 +Mercurial tiene una poderosa interfaz web que provee bastantes
   36.16 +capacidades útiles.
   36.17 +
   36.18 +Para uso interactivo, la interfaz le permite visualizar uno o varios
   36.19 +repositorios. Puede ver el historial de un repositorio, examinar cada
   36.20 +cambio (comentarios y diferencias), y ver los contenidos de cada
   36.21 +directorio y fichero.
   36.22 +
   36.23 +Adicionalmente la interfaz provee notificaciones RSS de los cambios de los
   36.24 +repositorios. Que le permite ``subscribirse''a un repositorio usando
   36.25 +su herramienta de lectura de notificaciones favorita, y ser notificado
   36.26 +automáticamente de la actividad en el repositorio tan pronto como
   36.27 +sucede. Me gusta mucho más este modelo que el estar suscrito a una
   36.28 +lista de correo a la cual se envían las notificaciones, dado que no
   36.29 +requiere configuración adicional de parte de quien sea que está
   36.30 +administrando el repositorio.
   36.31 +
   36.32 +La interfaz web también permite clonar repositorios a los usuarios
   36.33 +remotos, jalar cambios, y (cuando el servidor está configurado para
   36.34 +permitirlo) publicar cambios en el mismo.  El protocolo de entunelamiento
   36.35 +de Mercurial comprime datos agresivamente, de forma que trabaja
   36.36 +eficientemente incluso con conexiones de red con poco ancho de banda.
   36.37 +
   36.38 +La forma más sencilla de iniciarse con la interfaz web es usar su
   36.39 +navegador para visitar un repositorio existente, como por ejemplo el
   36.40 +repositorio principal de Mercurial \url{http://www.selenic.com/repo/hg?style=gitweb}.
   36.41 +
   36.42 +Si está interesado en proveer una interfaz web a sus propios
   36.43 +repositorios, Mercurial provee dos formas de hacerlo.  La primera es
   36.44 +usando la orden \hgcmd{serve}, que está enfocada a servir ``de forma
   36.45 +liviana'' y por intervalos cortos.  Para más detalles de cómo usar
   36.46 +esta orden vea la sección~\ref{sec:collab:serve} más adelante. Si
   36.47 +tiene un repositorio que desea hacer permanente, Mercurial tiene
   36.48 +soporte embebido del \command{ssh} para publicar cambios con seguridad
   36.49 +al repositorio central, como se documenta en la
   36.50 +sección~\ref{sec:collab:ssh}.  Es muy usual que se publique una copia
   36.51 +de sólo lectura en el repositorio que está corriendo sobre HTTP usando
   36.52 +CGI, como en la sección~\ref{sec:collab:cgi}.  Publicar sobre HTTP
   36.53 +satisface las necesidades de la gente que no tiene permisos de
   36.54 +publicación y de aquellos que quieren usar navegadores web para
   36.55 +visualizar el historial del repositorio.
   36.56 +
   36.57 +\subsection{Trabajo con muchas ramas}
   36.58 +
   36.59 +Los proyectos de cierta talla tienden naturalmente a progresar de
   36.60 +forma simultánea en varios frentes. En el caso del software, es común
   36.61 +que un proyecto tenga versiones periódicas oficiales. Una versión
   36.62 +puede entrar a ``modo mantenimiento'' por un tiempo después de su
   36.63 +primera publicación; las versiones de mantenimiento tienden a contener
   36.64 +solamente arreglos de fallos, pero no nuevas características. En
   36.65 +paralelo con las versiones de mantenimiento puede haber una o muchas
   36.66 +versiones futuras pueden estar en desarrollo. La gente usa normalmente
   36.67 +la palabra ``rama'' para referirse a una de las direcciones
   36.68 +ligeramente distintas en las cuales procede el desarrollo.
   36.69 +
   36.70 +Mercurial está especialmente preparado para administrar un buen número
   36.71 +de ramas simultáneas pero no idénticas. Cada ``dirección de
   36.72 +desarrollo'' puede vivir en su propio repositorio central, y puede
   36.73 +mezclar los cambios de una a otra de acuerdo con las necesidades. Dado
   36.74 +que los repositorios son independientes, uno del otro, los cambios
   36.75 +inestables de una rama de desarrollo nunca afectarán una rama estable
   36.76 +a menos que alguien explícitamente mezcle los cambios.
   36.77 +
   36.78 +A continuación un ejemplo de cómo podría hacerse esto en la
   36.79 +práctica. Digamos que tiene una ``rama principal'' en un servidor
   36.80 +central.
   36.81 +\interaction{branching.init}
   36.82 +Alguien lo clona, hace cambios locales, los prueba, y los publica allí
   36.83 +mismo.
   36.84 +
   36.85 +Una vez que la rama principal alcanza una estado de versión se puede
   36.86 +usar la orden \hgcmd{tag} para dar un nombre permanente a la revisión.
   36.87 +\interaction{branching.tag}
   36.88 +Digamos que en la rama principal ocurre más desarrollo.
   36.89 +\interaction{branching.main}
   36.90 +Cuando se usa la etiqueta con que se identificó la versión, la gente
   36.91 +puede clonar el repositorio en cualquier momento en el futuro
   36.92 +empleando \hgcmd{update} para obtener una copia del directorio de
   36.93 +trabajo exacta como cuando se creó la etiqueta de la revisión que se
   36.94 +consignó.
   36.95 +\interaction{branching.update}
   36.96 +
   36.97 +Adicionalmente, justo después de que la rama principal se etiquete,
   36.98 +alguien puede clonarla en el servidor a una nueva rama ``estable'',
   36.99 +también en el servidor.
  36.100 +\interaction{branching.clone}
  36.101 +
  36.102 +Alguien que requiera hacer un cambio en la rama estable puede clonar
  36.103 +\emph{ese} repositorio, hacer sus cambios, consignar y publicarlos
  36.104 +posteriormente al inicial.
  36.105 +\interaction{branching.stable}
  36.106 +Puesto que los repositorios de Mercurial son independientes, y que
  36.107 +Mercurial no mueve los cambios de un lado a otro automáticamente, las
  36.108 +ramas estable y principal están \emph{aisladas} la una de la otra.
  36.109 +Los cambios que haga en la rama principal no ``se filtran'' a la rama
  36.110 +estable o vice versa.
  36.111 +
  36.112 +Es usual que los arreglos de fallos de la rama estable deban hacerse
  36.113 +aparecer en la rama principal también.  En lugar de reescribir el
  36.114 +arreglo del fallo en la rama principal, puede jalar y mezclar los
  36.115 +cambios de la rama estable a la principal, Mercurial traerá tales
  36.116 +arreglos por usted.
  36.117 +\interaction{branching.merge}
  36.118 +La rama principal contendrá aún los cambios que no están en la
  36.119 +estable y contendrá además todos los arreglos de fallos de la rama
  36.120 +estable.  La rama estable permanece incólume a tales cambios.
  36.121 +
  36.122 +\subsection{Ramas de Características}
  36.123 +
  36.124 +En proyectos grandes, una forma efectiva de administrar los cambios es
  36.125 +dividir el equipo en grupos más pequeños. Cada grupo tiene una rama
  36.126 +compartida, clonada de una rama ``principal'' que conforma el proyecto
  36.127 +completo.   Aquellos que trabajan en ramas individuales típicamente
  36.128 +están aislados de los desarrollos de otras ramas.
  36.129 +
  36.130 +\begin{figure}[ht]
  36.131 +  \centering
  36.132 +  \grafix{feature-branches}
  36.133 +  \caption{Ramas de Características}
  36.134 +  \label{fig:collab:feature-branches}
  36.135 +\end{figure}
  36.136 +
  36.137 +Cuando una rama particular alcanza un estado deseado, alguien del
  36.138 +equipo de características jala y fusiona de la rama principal hacia
  36.139 +la rama de características y publica posteriormente a la rama principal.
  36.140 +
  36.141 +\subsection{El tren de publicación}
  36.142 +
  36.143 +Algunos proyectos se organizan al estilo``tren'': Una versión se
  36.144 +planifica para ser liberada cada cierto tiempo, y las características
  36.145 +que estén listas cuando ha llegado el momento ``tren'', se incorporan.
  36.146 +
  36.147 +Este modelo tiene cierta similitud a las ramas de características. La
  36.148 +diferencia es que cuando una característica pierde el tren, alguien en
  36.149 +el equipo de características jala y fusiona los cambios que se fueron
  36.150 +en la versión liberada hacia la rama de característica, y el trabajo
  36.151 +continúa sobre lo fusionado para que la característica logre estar en
  36.152 +la próxima versión.
  36.153 +
  36.154 +\subsection{El modelo del kernel linux}
  36.155 +
  36.156 +El desarrollo del Kernel Linux tiene una estructura jerárquica
  36.157 +bastante horizontal, rodeada de una nube de caos aparente. Dado que la
  36.158 +mayoría de desarrolladores usan \command{git}, una herramienta distribuida
  36.159 +de control de versiones con capacidades similares a Mercurial, resulta
  36.160 +de utilidad describir la forma en que el trabajo fluye en tal
  36.161 +ambiente; si le gustan las ideas, la aproximación se traduce bien
  36.162 +entre Git y Mercurial.
  36.163 +
  36.164 +En el centro de la comunidad está Linus Torvalds, el creador de Linux.
  36.165 +Él publica un único repositorio que es considerado el árbol
  36.166 +``oficial'' actual por la comunidad completa de
  36.167 +desarrolladores. Cualquiera puede clonar el árbol de Linus, pero él es
  36.168 +muy selectivo acerca de los árboles de los cuales jala.
  36.169 +
  36.170 +Linus tiene varios ``lugartenientes confiables''.  Como regla, él jala
  36.171 +todos los cambios que ellos publican, en la mayoría de los casos sin
  36.172 +siquiera revisarlos.  Algunos de sus lugartenientes generalmente
  36.173 +aceptan ser los ``mantenedores'', responsables de subsistemas
  36.174 +específicos dentro del kernel.  Si un hacker cualquiera desea hacer un
  36.175 +cambio a un subsistema y busca que termine en el árbol de Linus, debe
  36.176 +encontrar quién es el mantenedor del subsistema y solicitarle que
  36.177 +tenga en cuenta su cambio.  Si el mantenedor revisa los cambios y está
  36.178 +de acuerdo en tomarlos, estos pasarán al árbol de Linus de acuerdo a
  36.179 +lo expuesto.
  36.180 +
  36.181 +Cada lugarteniente tiene su forma particular de revisar, aceptar y
  36.182 +publicar los cambios; y para decidir cuando hacerlos presentes a
  36.183 +Linus.  Adicionalmente existen varias ramas conocidas que mucha gente
  36.184 +usa para propósitos distintos. Por ejemplo, pocas personas mantienen
  36.185 +repositorios ``estables'' de versiones anteriores del kernel, a los
  36.186 +cuales aplican arreglos de fallos críticos necesarios. Algunos
  36.187 +mantenedores publican varios árboles: uno para cambios
  36.188 +experimentales; uno para cambios que van a ofrecer al mantenedor
  36.189 +principal; y así sucesivamente. Otros publican un solo árbol.
  36.190 +
  36.191 +Este modelo tiene dos características notables. La primera es que son
  36.192 +de ``jalar exclusivamente''.  Usted debe solicitar, convencer o
  36.193 +incluso rogar a otro desarrollador para que tome sus cambios, porque
  36.194 +casi no hay árboles en los cuales más de una persona pueda publicar, y
  36.195 +no hay forma de publicar cambios en un árbol que otra persona controla.
  36.196 +
  36.197 +El segundo está basado en reputación y meritocracia.  Si usted es un
  36.198 +desconocido, Linus probablemente ignorará sus cambios, sin siquiera
  36.199 +responderle.  Pero un mantenedor de un subsistema probablemente los
  36.200 +revisara, y los acogerá en caso de que aprueben su criterio de
  36.201 +aplicabilidad.  A medida que usted ofrezca ``mejores'' cambios a un
  36.202 +mantenedor, habrá más posibilidad de que se confíe en su juicio y se
  36.203 +acepten los cambios.   Si usted es reconocido y mantiene una rama
  36.204 +durante bastante tiempo para algo que Linus no ha aceptado, personas
  36.205 +con intereses similares pueden jalar sus cambios regularmente para
  36.206 +estar al día con su trabajo.
  36.207 +
  36.208 +La reputación y meritocracia no necesariamente es transversal entre
  36.209 +``personas'' de diferentes subsistemas.  Si usted es respetado pero es
  36.210 +un hacker en almacenamiento y trata de arreglar un fallo de redes,
  36.211 +tal cambio puede recibir un nivel de escrutinio de un mantenedor de
  36.212 +redes comparable con el que se le haría a un completo extraño.
  36.213 +
  36.214 +Personas que vienen de proyectos con un ordenamiento distinto, sienten
  36.215 +que el proceso comparativamente caótico del Kernel Linux es
  36.216 +completamente lunático.  Es objeto de los caprichos individuales; la
  36.217 +gente desecha cambios cuando lo desean; y la fase de desarrollo es
  36.218 +alucinante. A pesar de eso Linux es una pieza de software exitosa y
  36.219 +bien reconocida.
  36.220 +
  36.221 +\subsection{Solamente jalar frente a colaboración pública}
  36.222 +
  36.223 +Una fuente perpetua de discusiones en la comunidad de código abierto
  36.224 +yace en el modelo de desarrollo en el cual la gente solamente jala
  36.225 +cambios de otros ``es mejor que'' uno  en el cual muchas personas
  36.226 +pueden publicar cambios a un repositorio compartido.
  36.227 +
  36.228 +Típicamente los partidarios del modelo de publicar usan las herramientas
  36.229 +que se apegan a este modelo.  Si usted usa una herramienta
  36.230 +centralizada de control de versiones como Subversion, no hay forma de
  36.231 +elegir qué modelo va a usar: La herramienta le ofrece publicación
  36.232 +compartida, y si desea hacer cualquier otra cosa, va a tener que
  36.233 +aplicar una aproximación artificial (tal como aplicar parches a mano).
  36.234 +
  36.235 +Una buena herramienta distribuida de control de versiones, tal como
  36.236 +Mercurial soportará los dos modelos.   Usted y sus colaboradores
  36.237 +pueden estructurar cómo trabajarán juntos basados en sus propias
  36.238 +necesidades y preferencias,  sin depender de las peripecias que la
  36.239 +herramienta les obligue a hacer.
  36.240 +
  36.241 +\subsection{Cuando la colaboración encuentra la administración ramificada}
  36.242 +
  36.243 +Una vez que usted y su equipo configurar algunos repositorios
  36.244 +compartidos y comienzan a propagar cambios entre sus repositorios
  36.245 +locales y compartidos, comenzará a encarar un reto relacionado, pero
  36.246 +un poco distinto:  Administrar las direcciones en las cuales su equipo
  36.247 +puede moverse.   A pesar de que está íntimamente ligado acerca de cómo
  36.248 +interactúa su equipo, es lo suficientemente denso para ameritar un
  36.249 +tratamiento en el capítulo~\ref{chap:branch}.
  36.250 +
  36.251 +\section{Aspectos técnicos de la colaboración}
  36.252 +
  36.253 +Lo que resta del capítulo lo dedicamos a las cuestiones de servir
  36.254 +datos a sus colaboradores.
  36.255 +
  36.256 +\section{Compartir informalmente con \hgcmd{serve}}
  36.257 +\label{sec:collab:serve}
  36.258 +
  36.259 +La orden \hgcmd{serve} de Mercurial satisface de forma espectacular
  36.260 +las necesidades de un grupo pequeño, acoplado y de corto
  36.261 +tiempo.  Se constituye en una demostración de cómo se siente usar los
  36.262 +comandos usando la red.
  36.263 +
  36.264 +Ejecute \hgcmd{serve} dentro de un repositorio, y en pocos segundos
  36.265 +iniciará un servidor HTTP especializado; aceptará conexiones desde
  36.266 +cualquier cliente y servirá datos de este repositorio mientrs lo
  36.267 +mantenga funcionando. Todo el que sepa el URL del servidor que ha
  36.268 +iniciado, y que puede comunicarse con su computador por la red, puede
  36.269 +usar un navegador web o Mercurial para leer datos del repositorio. Un
  36.270 +URL para una instancia de \hgcmd{serve} ejecutándose en un portátil
  36.271 +debería lucir algo \Verb|http://my-laptop.local:8000/|.
  36.272 +
  36.273 +La orden \hgcmd{serve} \emph{no} es un servidor web de propósito
  36.274 +general. Solamente puede hacer dos cosas:
  36.275 +\begin{itemize}
  36.276 +\item Permitir que se pueda visualizar el historial del repositorio que
  36.277 +  está sirviendo desde navegadores web.
  36.278 +\item Hablar el protocolo de conexión de Mercurial para que puedan hacer
  36.279 +  \hgcmd{clone} o \hgcmd{pull} (jalar) cambios de tal repositorio.
  36.280 +\end{itemize}
  36.281 +En particular, \hgcmd{serve} no permitirá que los usuarios remotos
  36.282 +puedan \emph{modificar} su repositorio.  Es de tipo solo lectura.
  36.283 +
  36.284 +Si está comenzando con Mercurial, no hay nada que le impida usar
  36.285 +\hgcmd{serve} para servir un repositorio en su propio computador, y
  36.286 +usar posteriormente órdenes como \hgcmd{clone}, \hgcmd{incoming}, para
  36.287 +comunicarse con el servidor como si el repositorio estuviera alojado
  36.288 +remotamente. Lo que además puede ayudarle a adecuarse rápidamente para
  36.289 +usar comandos en repositorios alojados en la red.
  36.290 +
  36.291 +\subsection{Cuestiones adicionales para tener en cuenta}
  36.292 +
  36.293 +Dado que permite lectura sin autenticación a todos sus clientes,
  36.294 +debería usar \hgcmd{serve} exclusivamente en ambientes en los cuáles
  36.295 +no tenga problema en que otros vean, o en los cuales tenga control
  36.296 +completo acerca de quien puede acceder a su red y jalar cambios de su
  36.297 +repositorio.
  36.298 +
  36.299 +La orden \hgcmd{serve} no tiene conocimiento acerca de programas
  36.300 +cortafuegos que puedan estar instalados en su sistema o en su red. No
  36.301 +puede detectar o controlar sus cortafuegos.  Si otras personas no
  36.302 +pueden acceder a su instancia \hgcmd{serve}, lo siguiente que debería hacer
  36.303 +(\emph{después} de asegurarse que tienen el URL correcto) es verificar
  36.304 +su configuración de cortafuegos.
  36.305 +
  36.306 +De forma predeterminada, \hgcmd{serve} escucha conexiones entrantes en
  36.307 +el puerto~8000.  Si otro proceso está escuchando en tal puerto, usted
  36.308 +podrá especificar un puerto distinto para escuchar con la opción
  36.309 +\hgopt{serve}{-p}.
  36.310 +
  36.311 +Normalmente, cuando se inicia \hgcmd{serve}, no imprime nada, lo cual
  36.312 +puede ser desconcertante.  Si desea confirmar que en efecto está
  36.313 +ejecutándose correctamente, y darse cuenta qué URL debería enviar a
  36.314 +sus colaboradores, inícielo con la opción \hggopt{-v}.
  36.315 +
  36.316 +\section{Uso del protocolo Secure Shell (ssh)}
  36.317 +\label{sec:collab:ssh}
  36.318 +
  36.319 +Usted puede publicar y jalar cambios en la red de forma segura usando
  36.320 +el protocolo Secure Shell (\texttt{ssh}).  Para usarlo satisfactoriamente,
  36.321 +tendrá que hacer algo de configuración a nivel de cliente o el
  36.322 +servidor.
  36.323 +
  36.324 +Si no está familiarizado con ssh, es un protocolo de red que le permite
  36.325 +comunicarse con seguridad con otro computador.  Para usarlo con
  36.326 +Mercurial, estará estableciendo una o más cuentas de usuario en un
  36.327 +servidor de forma tal que los usuarios remotos puedan entrar y
  36.328 +ejecutar órdenes.
  36.329 +
  36.330 +(Si ssh le \emph{es} familiar, encontrará probablemente elemental una
  36.331 +porción del material a continuación.)
  36.332 +
  36.333 +\subsection{Cómo leer y escribir URLs de ssh}
  36.334 +
  36.335 +Los URLs de ssh tienden a lucir de la siguiente forma:
  36.336 +\begin{codesample2}
  36.337 +  ssh://bos@hg.serpentine.com:22/hg/hgbook
  36.338 +\end{codesample2}
  36.339 +\begin{enumerate}
  36.340 +\item La parte ``\texttt{ssh://}'' indica a Mercurial que use el
  36.341 +  protocolo ssh.
  36.342 +\item El componente ``\texttt{bos@}'' indica el nombre del usuario que
  36.343 +  está entrando al servidor.  Puede omitirlo si el usuario remoto
  36.344 +  coincide con el usuario local.
  36.345 +\item ``\texttt{hg.serpentine.com}'' es el nombre del servidor al cual
  36.346 +  se desea entrar.
  36.347 +\item El ``:22'' identifica el número del puerto en el servidor al cual
  36.348 +  se conectará.  El predeterminado es el~22, así que solamente
  36.349 +  necesitará especificar esa porción si \emph{no} está usando el
  36.350 +  puerto~22.
  36.351 +\item La última porción del URL es la ruta local al repositorio en el
  36.352 +  servidor.
  36.353 +\end{enumerate}
  36.354 +
  36.355 +El componente de la ruta del URL para ssh es una fuente de confusión,
  36.356 +puesto que no hay una forma estándar para que las herramientas puedan
  36.357 +interpretarlo.  Algunos programas se comportan de manera distinta a
  36.358 +otros cuando manipulan estas rutas.  No es la situación ideal, pero
  36.359 +es muy poco probable que vaya a cambiar.  Por favor lea los párrafos
  36.360 +siguientes cuidadosamente.
  36.361 +
  36.362 +Mercurial trata la ruta al repositorio en el servidor como relativo al
  36.363 +directorio personal del usuario remoto.  Por ejemplo, si el usuario
  36.364 +\texttt{foo} en el servidor tiene el directorio casa
  36.365 +\dirname{/home/foo},
  36.366 +entonces un URL ssh que contenga en su ruta a \dirname{bar}
  36.367 +\emph{realmente} se refiere al directorio \dirname{/home/foo/bar}.
  36.368 +
  36.369 +Si desea especificar una ruta relativa a otro directorio de usuario,
  36.370 +puede usar una ruta que comience con un caracter tildado, seguido del
  36.371 +nombre del usuario (llamémosle \texttt{otrousuario}, así
  36.372 +\begin{codesample2}
  36.373 +  ssh://server/~otrousuario/hg/repo
  36.374 +\end{codesample2}
  36.375 +
  36.376 +Y si realmente desea especifica una ruta \emph{absoluta} en el
  36.377 +servidor, comience con el componente de la ruta con dos barras como
  36.378 +en el siguiente ejemplo:
  36.379 +\begin{codesample2}
  36.380 +  ssh://server//absolute/path
  36.381 +\end{codesample2}
  36.382 +
  36.383 +\subsection{Encontrar un cliente ssh para su sistema}
  36.384 +
  36.385 +Casi todos los sistemas tipo Unix vienen con OpenSSH preinstalado.  Si
  36.386 +usted está usando un sistema de estos, ejecute \Verb|which ssh| para
  36.387 +identificar dónde está instalada la orden \command{ssh} (usualmente
  36.388 +estará en \dirname{/usr/bin}).  Si por casualidad no está presente,
  36.389 +vea la documentación de sus sistema para lograr instalarlo.
  36.390 +
  36.391 +En Windows, tendrá que escoger primero un cliente adecuado para
  36.392 +descargarlo.  Hay dos alternativas:
  36.393 +\begin{itemize}
  36.394 +\item El excelente paquete PuTTY~\cite{web:putty} de Simon Tatham, que
  36.395 +  ofrece un suite completo de órdenes de cliente ssh.
  36.396 +\item Si tiene alta tolerancia al dolor, puede usar el porte de Cygwin
  36.397 +  para OpenSSH.
  36.398 +\end{itemize}
  36.399 +En cualquier caso, tendrá que editar su fichero \hgini\ para indicarle
  36.400 +a Mercurial dónde encontrar la orden real del cliente.  Por ejemplo, si
  36.401 +está usando PuTTY, tendrá que usar la orden \command{plink} como un
  36.402 +cliente de línea de órdenes.
  36.403 +\begin{codesample2}
  36.404 +  [ui]
  36.405 +  ssh = C:/ruta/a/plink.exe -ssh -i "C:/ruta/a/mi/llave/privada"
  36.406 +\end{codesample2}
  36.407 +
  36.408 +\begin{note}
  36.409 +  La ruta a \command{plink} no debería contener espacios o caracteres
  36.410 +  en blanco, o Mercurial no podrá encontrarlo correctamente (por lo
  36.411 +  tanto, probablemente no sería buena idea colocarlo en 
  36.412 +  \dirname{C:\\Program Files}
  36.413 +\end{note}
  36.414 +
  36.415 +\subsection{Generar un par de llaves}
  36.416 +
  36.417 +Para evitar la necesidad de teclear una clave de forma repetitiva cada
  36.418 +vez que necesita usar el cliente, recomiendo generar un par de llaves.
  36.419 +En un sistema tipo Unix, la orden \command{ssh-keygen} también se
  36.420 +comportará bien. En Windows, si está usando PuTTY, la orden
  36.421 +\command{puttygen} es la que necesitará.
  36.422 +
  36.423 +Cuando genera un par de llaves, se aconseja \emph{comedidamente} 
  36.424 +protegerlas con una frase de clave.  (La única oportunidad en la cual
  36.425 +usted querría identificarse una única vez, es cuando está usando
  36.426 +el protocolo ssh para tareas automatizadas en una red segura.)
  36.427 +
  36.428 +No basta con generar un par de llaves.  Se requiere adicionar una llave
  36.429 +pública al conjunto de llaves autorizadas para todos los usuarios
  36.430 +remotos que se vayan a autenticar.  Para aquellos servidores que usen
  36.431 +OpenSSH (la gran mayoría), significará añadir la llave pública a la
  36.432 +lista en el fichero llamado \sfilename{authorized\_keys} en su
  36.433 +directorio \sdirname{.ssh}.
  36.434 +
  36.435 +En sistemas tipo Unix, su llave pública tendrá la extensión
  36.436 +\filename{.pub}.  Si usa \command{puttygen} en Windows, puede
  36.437 +guardar la llave pública en un fichero de su elección, o pegarla desde
  36.438 +la ventana en la cual se despliega directamente en el fichero
  36.439 +\sfilename{authorized\_keys}.
  36.440 +
  36.441 +\subsection{Uso de un agente de autenticación}
  36.442 +
  36.443 +Un agente de autenticación es un demonio que almacena frases clave en
  36.444 +memoria (olvidará las frases clave si sale y vuelve a entrar).  Un cliente
  36.445 +ssh notará si está corriendo, y solicitará una frase clave.  Si no hay
  36.446 +un agente de autenticación corriendo, o el agente no almacena la frase
  36.447 +clave necesaria, tendrá que teclear su frase clave cada vez que 
  36.448 +Mercurial intente comunicarse con un servidor para usted (p.e.~cada vez
  36.449 +que jale o publique cambios).
  36.450 +
  36.451 +El problema de almacenar frases claves en un agente es que es posible
  36.452 +para un atacante bien preparado recuperar el texto plano de su frase
  36.453 +clave, en algunos casos incluso si su sistema sea muy alternante.
  36.454 +Es su decisión si es un riesgo aceptable.  Lo que si es seguro es que
  36.455 +evita reteclear.
  36.456 +
  36.457 +En sistemas tipo Unix, el agente se llama \command{ssh-agent}, y
  36.458 +usualmente se ejecuta automáticamente cuando usted entra.  Tendrá que
  36.459 +usar la orden \command{ssh-add} para añadir frases claves al agente.  En
  36.460 +Windows, si está usando PuTTY, la orden \command{pageant} actúa como
  36.461 +el agente.  Añade un icono a su barra del sistema que le permitirá
  36.462 +almacenar frases clave.
  36.463 +
  36.464 +\subsection{Configurar el lado del servidor apropiadamente}
  36.465 +
  36.466 +Dado que puede ser dispendioso configurar ssh si usted es nuevo, hay 
  36.467 +una variedad de cosas que podrían ir mal.  Añada piense primero en
  36.468 +Mercurial y hay mucho más en qué pensar.  La mayor parte de estos
  36.469 +problemas potenciales ocurren en el lado del servidor, no en el cliente.
  36.470 +Las buenas noticias es que una vez tiene una configuración funcional,
  36.471 +usualmente continuará trabajando indefinidamente.
  36.472 +
  36.473 +Antes de intentar que Mercurial hable con un servidor ssh, es mejor
  36.474 +asegurarse que puede usar la orden normal \command{ssh} o \command{putty}
  36.475 +para comunicarse con el servidor primero.  Si tiene problemas usando
  36.476 +estas órdenes directamente, de seguro Mercurial no funcionará.  Pero aún,
  36.477 +esconderá el problema subyacente.  Cuando desee revisar un problema
  36.478 +relacionado con ssh y Mercurial, debería asegurarse primero que las
  36.479 +órdenes de ssh en el lado del cliente funcionan primero, \emph{antes}
  36.480 +de preocuparse por si existe un problema con Mercurial.
  36.481 +
  36.482 +Lo primero para asegurar en el lado del servidor es que puede entrar
  36.483 +desde otra máquina.  Si no puede entrar con \command{ssh} o 
  36.484 +\command{putty}, el mensaje de error que obtenga le puede dar pistas
  36.485 +de qué ha ido mal.  Los problemas más comunes son los siguientes:
  36.486 +\begin{itemize}
  36.487 +\item Si obtiene un error de ``conexión rehusada'', es posible que no 
  36.488 +  haya un demonio SSH corriendo en el servidor o que no pueda accederse
  36.489 +  a él por configuraciones de cortafuegos.
  36.490 +\item Si obtiene un error de ``no hay ruta hasta el servidor'', puede
  36.491 +  tener la dirección del servidor incorrecta o un cortafuegos con
  36.492 +  bloqueo agresivo que no permitirá su existencia.
  36.493 +\item Si obtiene un mensaje de ``permiso denegado'', puede que haya
  36.494 +  tecleado mal el usuario en el servidor, o que haya tecleado
  36.495 +  incorrectamente la frase clave o la clave del usuario remoto.
  36.496 +\end{itemize}
  36.497 +En resumen, si tiene problemas al comunicarse con el demonio ssh del
  36.498 +servidor, primero asegúrese de que está corriendo.  En muchos sistemas
  36.499 +estará instalado, pero deshabilitado de forma predeterminada.  Una vez
  36.500 +que haya hecho este paso tendrá que revisar si el cortafuegos del
  36.501 +servidor está configurado para recibir conexiones entrantes en el
  36.502 +puerto en el cual el demonio de ssh está escuchando (usualmente el~22).
  36.503 +No trate de buscar otras posibilidades exóticas o configuraciones
  36.504 +erradas hasta que haya revisado primero estas dos.
  36.505 +
  36.506 +Si está usando un agente de autenticación en el lado del cliente para
  36.507 +almacenar las frase claves de sus contraseñas, debería poder entrar al
  36.508 +servidor sin necesidad de que se le solicite frases claves o
  36.509 +contraseñas.  Si se le pregunta alguna, a continuación algunas
  36.510 +posibilidades:
  36.511 +\begin{itemize}
  36.512 +\item Puede haber olvidado usar \command{ssh-add} o
  36.513 +  \command{pageant} para guardar la frase clave.
  36.514 +\item Puede haber almacenado una frase clave errónea para la llave.
  36.515 +\end{itemize}
  36.516 +Si se le solicita la clave del usuario remoto, hay otras posibilidades
  36.517 +que deben revisarse:
  36.518 +\begin{itemize}
  36.519 +\item O bien el directorio del usuario o su directorio \sdirname{.ssh}
  36.520 +  tiene permisos excesivamente abiertos.  Como resultado el daemonio
  36.521 +  ssh no creerá o leerá su fichero \sfilename{authorized\_keys}.  
  36.522 +  Por ejemplo, un directorio casa o \sdirname{.ssh} causará aveces
  36.523 +  este síntoma.
  36.524 +\item El fichero de usuario \sfilename{authorized\_keys} puede tener
  36.525 +  un problema.  Si alguien distinto al usuario es dueño o puede
  36.526 +  escribir el fichero, el demonio ssh no confiará o lo leerá.
  36.527 +\end{itemize}
  36.528 +
  36.529 +En un mundo ideal, debería poder ejecutar la siguiente orden
  36.530 +exitosamente, y debería imprimir exactamente una línea de salida,
  36.531 +la fecha y hora actual.
  36.532 +\begin{codesample2}
  36.533 +  ssh miservidor fecha
  36.534 +\end{codesample2}
  36.535 +
  36.536 +Si en su servidor tiene guión que se ejecuta a la entrada e imprime
  36.537 +letreros o cualquier otra cosa, incluso cuando se ejecutan órdenes no
  36.538 +interactivas como esta, debería arreglarlo antes de continuar, de
  36.539 +forma que solamente imprima algo si se ejecuta interactivamente.  De
  36.540 +otra forma estos letreros al menos llenarán la salida de Mercurial. 
  36.541 +Incluso podrían causar problemas potenciales cuando se ejecuten
  36.542 +órdenes de forma remota.  Mercurial intenta detectar e ignorar los
  36.543 +letreros en sesiones no interactivas de \command{ssh}, pero no es
  36.544 +a prueba de tontos.  (Si edita sus guiones de entrada en el servidor,
  36.545 +la forma usual de ver si un guión de línea de comandos se ejecuta en un intérprete
  36.546 +interactivo, es verificar el código de retorno de la orden
  36.547 +\Verb|tty -s|.)
  36.548 +
  36.549 +Cuando verifique que el venerado ssh funciona en su servidor, el
  36.550 +paso siguiente es asegurar que Mercurial corre en el servidor.  La
  36.551 +orden siguiente debería ejecutarse satisfactoriamente:
  36.552 +\begin{codesample2}
  36.553 +  ssh miservidor hg version
  36.554 +\end{codesample2}
  36.555 +Si ve un mensaje de error en lugar de la salida usual de 
  36.556 +\hgcmd{version}, será porque no ha instalado Mercurial en
  36.557 +\dirname{/usr/bin}.  No se preocupe si este es el caso; no necesita
  36.558 +hacerlo.  Pero debería revisar los posibles problemas presentados a
  36.559 +continuación:
  36.560 +\begin{itemize}
  36.561 +\item Está instalado Mercurial en el servidor?  Se que suena trivial
  36.562 +  pero es mejor revisar!
  36.563 +\item Tal vez la ruta de búsqueda de la interfaz de órdenes
  36.564 +  (normalmente vía la variable de ambiente \envar{PATH}) simplemente
  36.565 +  está mal configurada.
  36.566 +\item Puede ser que su variable de ambiente \envar{PATH} soalamente
  36.567 +  apunte al lugar en el cual está el ejecutable \command{hg} si la
  36.568 +  sesión de entrada es interactiva.  Puede suceder si establece la
  36.569 +  ruta en el guión de línea de comandos de entrada incorrecto.  Consulte la
  36.570 +  documentación de su línea de órdenes.
  36.571 +\item La variable de ambiente \envar{PYTHONPATH} puede requerir la
  36.572 +  ruta a los módulos de Mercurial en Python.  Puede que ni siquiera
  36.573 +  está establecida; podría estar incorrecta; o puede ser que se
  36.574 +  establezca únicamente cuando hay entradas interactivas.
  36.575 +\end{itemize}
  36.576 +
  36.577 +Si puede ejecutar \hgcmd{version} sobre una conexión ssh,
  36.578 +felicitaciones!  Ha logrado la interacción entre el cliente y el 
  36.579 +servidor.  Ahora debería poder acceder a los repositorios de
  36.580 +Mercurial que tiene el usuario en el servidor.  Si tiene problemas
  36.581 +con Mercurial y ssh en este punto, intente usar la opción
  36.582 +\hggopt{--debug} para tener información más clara de lo que está
  36.583 +sucediendo.
  36.584 +
  36.585 +\subsection{Compresión con ssh}
  36.586 +
  36.587 +Mercurial no comprime datos cuando usa el protocolo ssh, dado que
  36.588 +el protocolo puede comprimir datos transparentemente.  Pero el
  36.589 +comportamiento predeterminado del cliente ssh es \emph{no}
  36.590 +solicitar compresión.
  36.591 +
  36.592 +Sobre cualquier red distinta a una LAN rápida (incluso con una red
  36.593 +inalámbrica), hacer uso de compresión puede mejorar el rendimiento
  36.594 +de las operaciones de Mercurial que involucren la red.  Por ejemplo,
  36.595 +sobre WAN, alguien ha medido la compresión reduciendo la cantidad
  36.596 +de tiempo requerido para clonar un repositorio particularmente
  36.597 +grande de~51 minutos a~17 minutos.
  36.598 +
  36.599 +Tanto \command{ssh} como \command{plink} aceptan la opción
  36.600 +\cmdopt{ssh}{-C} que activa la compresión.  Puede editar fácilmente
  36.601 +su \hgrc\ para habilitar la compresión para todos los usos de
  36.602 +Mercurial sobre el protocolo ssh.
  36.603 +\begin{codesample2}
  36.604 +  [ui]
  36.605 +  ssh = ssh -C
  36.606 +\end{codesample2}
  36.607 +
  36.608 +Si usa \command{ssh}, puede reconfigurarlo para que siempre use
  36.609 +compresión cuando se comunique con su servidor.  Para hacerlo,
  36.610 +edite su fichero \sfilename{.ssh/config} (que puede no existir
  36.611 +aún), de la siguiente forma:
  36.612 +\begin{codesample2}
  36.613 +  Host hg
  36.614 +    Compression yes
  36.615 +    HostName hg.ejemplo.com
  36.616 +\end{codesample2}
  36.617 +Que define un alias, \texttt{hg}.  Cuando lo usa con la orden
  36.618 +\command{ssh} o con una URL de Mercurial con protocolo\texttt{ssh},
  36.619 +logrará que \command{ssh} se conecte a \texttt{hg.ejemplo.com}
  36.620 +con compresión.  Que le dará un nombre más corto para teclear y
  36.621 +compresión, los cuales por derecho propio son buenos.
  36.622 +
  36.623 +\section{Uso de CGI a través de HTTP}
  36.624 +\label{sec:collab:cgi}
  36.625 +
  36.626 +Dependiendo de qué tan ambicioso sea, configurar la interfaz CGI
  36.627 +de Mercurial puede tomar desde unos minutos hasta varias horas.
  36.628 +
  36.629 +Comenzaremos con el ejemplo más sencillo, y nos dirigiremos hacia
  36.630 +configuraciones más complejas.  Incluso para el caso más básico
  36.631 +necesitará leer y modificar su configuración del servidor web.
  36.632 +
  36.633 +\begin{note}
  36.634 +  Configurar un servidor web es una actividad compleja, engorrosa y
  36.635 +  altamente dependiente del sistema.  De ninguna manera podremos
  36.636 +  cubrir todos los casos posibles con los cuales pueda encontrarse.
  36.637 +  Use su discreción y juicio respecto a las secciones siguientes.
  36.638 +  Esté preparado para cometer muchas equivocaciones, y emplear
  36.639 +  bastante tiempo leyendo sus bitácoras de error del servidor.
  36.640 +\end{note}
  36.641 +
  36.642 +\subsection{Lista de chequeo de la configuración del servidor web}
  36.643 +
  36.644 +Antes de continuar, tómese un tiempo para revisar ciertos aspectos de
  36.645 +la configuración de su sistema:
  36.646 +
  36.647 +\begin{enumerate}
  36.648 +\item ¿Tiene un servidor web?  Mac OS X viene con Apache, pero otros
  36.649 +  sistemas pueden no tener un servidor web instalado.
  36.650 +\item Si tiene un servidor web instalado, ¿Está ejecutándose?  En la
  36.651 +  mayoría de sistemas, aunque esté presente, puede no estar habilitado
  36.652 +  de forma predeterminada.
  36.653 +\item ¿u servidor está configurado para permitir ejecutar programas
  36.654 +  CGI en el directorio donde planea hacerlo?  Casi todos los
  36.655 +  servidores de forma predeterminada explícitamente inhiben la
  36.656 +  habilidad de ejecutar programas CGI.
  36.657 +\end{enumerate}
  36.658 +
  36.659 +Si no tiene un servidor web instalado, y no tiene cierta experiencia
  36.660 +configurando  Apache, debería considerar usar el servidor web
  36.661 +\texttt{lighttpd} en lugar de Apache.  Apache tiene una reputación
  36.662 +bien ganada por su configuración barroca y confusa.
  36.663 +A pesar de que \texttt{lighttpd} tiene menos características que
  36.664 +Apache en ciertas áreas, las mismas no son relevantes para servir
  36.665 +repositorios de Mercurial.  Definitivamente es mucho más sencillo
  36.666 +comenzar con \texttt{lighttpd} que con Apache.
  36.667 +
  36.668 +\subsection{Configuración básica de CGI}
  36.669 +
  36.670 +En sistemas tipo Unix es común que los usuarios tengan un subdirectorio
  36.671 +con un nombre como \dirname{public\_html} en su directorio personal,
  36.672 +desde el cual pueden servir páginas web.  Un fichero llamado \filename{foo}
  36.673 +en este directorio será visible en una URL de la forma
  36.674 +\texttt{http://www.example.com/\~username/foo}.
  36.675 +
  36.676 +Para comenzar, encuentre el guión \sfilename{hgweb.cgi} que debería
  36.677 +estar presente en su instalación de Mercurial.  Si no puede
  36.678 +encontrarlo rápidamente una copia local en su sistema, puede
  36.679 +descargarlo del repositorio principal de Mercurial en
  36.680 +\url{http://www.selenic.com/repo/hg/raw-file/tip/hgweb.cgi}.
  36.681 +
  36.682 +Tendrá que copiar este guión en su directorio \dirname{public\_html},
  36.683 +y asegurarse que sea ejecutable.
  36.684 +\begin{codesample2}
  36.685 +  cp .../hgweb.cgi ~/public_html
  36.686 +  chmod 755 ~/public_html/hgweb.cgi
  36.687 +\end{codesample2}
  36.688 +El argumento \texttt{755} de la orden \command{chmod} es un poco más
  36.689 +general que hacerlo ejecutable: Asegura que el guión sea ejecutable
  36.690 +por cualquiera, y que el ``grupo'' y los ``otros'' \emph{no}  tengan
  36.691 +permiso de escritura.  Si dejara los permisos de escritura abiertos,
  36.692 +, el subsistema \texttt{suexec} de  Apache probablemente se negaría
  36.693 +a ejecutar el guión.  De hecho, \texttt{suexec} también insiste en que
  36.694 +el \emph{directorio} en el cual reside el guión no tenga permiso de
  36.695 +escritura para otros.
  36.696 +\begin{codesample2}
  36.697 +  chmod 755 ~/public_html
  36.698 +\end{codesample2}
  36.699 +
  36.700 +\subsubsection{¿Qué \emph{podría} resultar mal?}
  36.701 +\label{sec:collab:wtf}
  36.702 +
  36.703 +Cuando haya ubicado el CGI en el sitio correspondiente con un navegador
  36.704 +intente visitar el URL \url{http://myhostname/~myuser/hgweb.cgi},
  36.705 +\emph{sin} dejarse abatir por un error.  Hay una alta probabilidad de
  36.706 +que esta primera visita al URL sea fallida, y hay muchas razones posibles
  36.707 +para este comportamiento.  De hecho, podría toparse con cada uno de los
  36.708 +errores que describimos a continuación, así que no deje de leerlos
  36.709 +cuidadosamente.   A continuación presento los problemas que yo tuve en
  36.710 +un sistema con Fedora~7, con una instalación nueva de Apache, y una
  36.711 +cuenta de usuario que creé específicamente para desarrollar este
  36.712 +ejercicio.
  36.713 +
  36.714 +Su servidor web puede tener directorios por usuario deshabilitados. Si
  36.715 +usa Apache, busque el fichero de configuración que contenga la
  36.716 +directiva \texttt{UserDir}.  Si no está presente en sitio alguno, los
  36.717 +directorios por usuario están deshabilitados.  Si la hay, pero su
  36.718 +valor es \texttt{disabled}, los directorios por usuario estarán
  36.719 +deshabilitados. La directiva \texttt{UserDir} en caso contrario tendrá
  36.720 +el nombre del subdirectorio bajo el cual Apache mirará en el
  36.721 +directorio de cada usuario, por ejemplo \dirname{public\_html}.
  36.722 +
  36.723 +Los permisos de sus ficheros pueden ser demasiado restrictivos.  El
  36.724 +servidor web debe poder recorrer su directorio personal y los
  36.725 +directorios que estén bajo \dirname{public\_html}, además de tener
  36.726 +permiso para leer aquellos que estén adentro.  A continuación una
  36.727 +receta rápida para hacer que sus permisos estén acordes con las
  36.728 +necesidades básicas.
  36.729 +\begin{codesample2}
  36.730 +  chmod 755 ~
  36.731 +  find ~/public_html -type d -print0 | xargs -0r chmod 755
  36.732 +  find ~/public_html -type f -print0 | xargs -0r chmod 644
  36.733 +\end{codesample2}
  36.734 +
  36.735 +Otra posibilidad con los permisos es que obtenga una ventana
  36.736 +completamente en blanco cuando trata de cargar el guión. En cuyo
  36.737 +caso, es posible que los permisos que tiene son \emph{demasiado
  36.738 + permisivos}.  El subsistema \texttt{suexec} de Apache no ejecutará un
  36.739 +guión que tenga permisos de escritura para el grupo o el planeta, por
  36.740 +ejemplo.
  36.741 +
  36.742 +Su servidor web puede estar configurado para evitar la ejecución de
  36.743 +programas CGI en los directorios de usuario.  A continuación presento
  36.744 +una configuración predeterminada por usuario en mi sistema Fedora.
  36.745 +
  36.746 +\begin{codesample2}
  36.747 +  <Directory /home/*/public_html>
  36.748 +      AllowOverride FileInfo AuthConfig Limit
  36.749 +      Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
  36.750 +      <Limit GET POST OPTIONS>
  36.751 +          Order allow,deny
  36.752 +          Allow from all
  36.753 +      </Limit>
  36.754 +      <LimitExcept GET POST OPTIONS>
  36.755 +          Order deny,allow
  36.756 +          Deny from all
  36.757 +      </LimitExcept>
  36.758 +  </Directory>
  36.759 +\end{codesample2}
  36.760 +Si encuentra un grupo de instrucciones de \texttt{Directory} similares
  36.761 +en su configuración de Apache,  la directiva a revisar es \texttt{Options}.
  36.762 +Adicione \texttt{ExecCGI} al final de esta lista en caso de que haga
  36.763 +falta y reinicie su servidor web.
  36.764 +
  36.765 +Si resulta que Apache le muestra el texto del guión CGI en lugar de
  36.766 +ejecutarlo, necesitará o bien descomentar (si se encuentra presente) o
  36.767 +adicionar una directiva como la siguiente:
  36.768 +\begin{codesample2}
  36.769 +  AddHandler cgi-script .cgi
  36.770 +\end{codesample2}
  36.771 +
  36.772 +Otra posibilidad es que observe una traza de Python en colores
  36.773 +informando que no puede importar un módulo relacionado con
  36.774 +\texttt{mercurial}.  Esto es un gran progreso!  El servidor es capaz
  36.775 +de ejecutar su guión CGI.  Este error solamente ocurrirá si está
  36.776 +ejecutando una instalación privada de Mercurial en lugar de una
  36.777 +instalación para todo el sistema.  Recuerde que el servidor que
  36.778 +ejecuta el programa CGI no cuenta con variables de ambiente de las
  36.779 +cuales usted si dispone en una sesión interactiva.  Si este error le
  36.780 +ocurre, edite su copia de \sfilename{hgweb.cgi} y siga las indicaciones
  36.781 +dentro del mismo para establecer de forma adecuada su variable de
  36.782 +ambiente \envar{PYTHONPATH}.
  36.783 +
  36.784 +Finalmente, si encuentra \emph{otra} traza a todo color de Python al visitar
  36.785 +el URL: Esta seguramente se referirá a que no puede encontrar
  36.786 +\dirname{/path/to/repository}.  Edite su script \sfilename{hgweb.cgi}
  36.787 +y reemplace la cadena \dirname{/path/to/repository} con la ruta
  36.788 +completa al repositorio que desea servir.
  36.789 +
  36.790 +En este punto, cuando trate de recargar la página, deberá visualizar
  36.791 +una linda vista HTML del historial de su repositorio. Uff!
  36.792 +
  36.793 +\subsubsection{Configuración de lighttpd}
  36.794 +
  36.795 +En mi intención de ser exhaustivo, intenté configurar
  36.796 +\texttt{lighttpd}, un servidor web con creciente aceptación, para
  36.797 +servir los repositorios de la misma forma como lo describí
  36.798 +anteriormente con Apache. Después de superar los problemas que mostré
  36.799 +con Apache, muchos de los cuáles no son específicos del servidor.  Por
  36.800 +lo tanto estaba seguro de que mis permisos para directorios y ficheros
  36.801 +eran correctos y que mi guión \sfilename{hgweb.cgi} también lo era.
  36.802 +
  36.803 +Dado que ya Apache estaba en ejecución correctamente, lograr que
  36.804 +\texttt{lighttpd} sirviera mi repositorio fue rápido (en otras
  36.805 +palabras, si está tratando de usar \texttt{lighttpd}, debe leer la
  36.806 +sección de Apache).  Primero tuve que editar la sección
  36.807 +\texttt{mod\_access} para habilitar \texttt{mod\_cgi} y
  36.808 +\texttt{mod\_userdir}, los cuales estaban inhabilitados en mi
  36.809 +instalación predeterminada.  Añadí posteriormente unas líneas al final
  36.810 +del fichero de configuración, para hacer lo propio con los módulos.
  36.811 +\begin{codesample2}
  36.812 +  userdir.path = "public_html"
  36.813 +  cgi.assign = ( ".cgi" => "" )
  36.814 +\end{codesample2}
  36.815 +Hecho esto, \texttt{lighttpd} funcionó inmediatamente para
  36.816 +mí. Configuré \texttt{lighttpd} antes que Apache, tuve casi los mismos
  36.817 +reparos a nivel de configuración del sistema que con Apache.  De todas
  36.818 +maneras, considero que \texttt{lighttpd} es bastante más sencillo de
  36.819 +configurar que Apache, a pesar de haber usado Apache por lo menos por
  36.820 +una década, y esta fue mi primera experiencia con \texttt{lighttpd}.
  36.821 +
  36.822 +\subsection{Compartir varios repositorios con un guión CGI}
  36.823 +
  36.824 +El guión \sfilename{hgweb.cgi} permite publicar únicamente un
  36.825 +repositorio, una restricción frustrante.  Si desea publicar más de uno
  36.826 +sin complicarse con varias copias del mismo guión, cada una con un
  36.827 +nombre distinto, resulta mucho mejor usar el guión
  36.828 +\sfilename{hgwebdir.cgi}.
  36.829 +
  36.830 +El procedimiento para configurar \sfilename{hgwebdir.cgi} tiene una
  36.831 +porción adicional frente al trabajo requerido con
  36.832 +\sfilename{hgweb.cgi}.  Primero se debe obtener una copia del
  36.833 +guión. Si no tiene una a mano, puede descargar una copia del ftp
  36.834 +principal del repositorio de Mercurial en
  36.835 +\url{http://www.selenic.com/repo/hg/raw-file/tip/hgwebdir.cgi}.
  36.836 +
  36.837 +Necesitará una copia del guión en su directorio \dirname{public\_html},
  36.838 +y asegurarse de que sea ejecutable.
  36.839 +\begin{codesample2}
  36.840 +  cp .../hgwebdir.cgi ~/public_html
  36.841 +  chmod 755 ~/public_html ~/public_html/hgwebdir.cgi
  36.842 +\end{codesample2}
  36.843 +Con la configuración básica, intente visitar en su navegador
  36.844 +\url{http://myhostname/~myuser/hgwebdir.cgi}.  Debería mostrar una
  36.845 +lista vacía de repositorios.  Si obtiene una ventana en blanco o un
  36.846 +mensaje de error, verifique la lista de problemas potenciales en la 
  36.847 +sección~\ref{sec:collab:wtf}.
  36.848 +
  36.849 +El guión \sfilename{hgwebdir.cgi} se apoya en un fichero externo de
  36.850 +configuración.  En principio, busca un fichero llamado
  36.851 +\sfilename{hgweb.config} en el mismo directorio.  Tendrá que crear el
  36.852 +fichero, y permitir lectura de todo el mundo.  El formato del fichero
  36.853 +es similar a un fichero ``ini'' de Windows, que puede interpretar el módulo
  36.854 +\texttt{ConfigParser}~\cite{web:configparser} de Python.
  36.855 +
  36.856 +La forma más sencilla de configurar \sfilename{hgwebdir.cgi} es con
  36.857 +una sección llamada \texttt{collections}.  Esta publicará automáticamente
  36.858 +\emph{todos} los repositorios en los directorios que usted
  36.859 +especifique.  La sección debería lucir así:
  36.860 +\begin{codesample2}
  36.861 +  [collections]
  36.862 +  /mi/ruta = /mi/ruta
  36.863 +\end{codesample2}
  36.864 +Mercurial lo interpreta buscando el nombre del directorio que esté a la
  36.865 +\emph{derecha} del símbolo ``\texttt{=}''; encontrando repositorios en
  36.866 +la jerarquía de directorios; y usando el texto a la \emph{izquierda}
  36.867 +para eliminar el texto de los nombres que mostrará en la interfaz
  36.868 +web.  El componente restante de la ruta después de esta eliminación
  36.869 +usualmente se llama ``ruta virtual''.
  36.870 +
  36.871 +Dado el ejemplo de arriba, si tenemos un repositorio cuya ruta local es
  36.872 +\dirname{/mi/ruta/este/repo}, el guión CGI eliminará la porción inicial
  36.873 +\dirname{/mi/ruta} del nombre y publicará el repositorio con una ruta
  36.874 +virtual \dirname{este/repo}.  Si el URL base de nuestro guión CGI es
  36.875 +\url{http://myhostname/~myuser/hgwebdir.cgi}, el URL completo al
  36.876 +repositorio será
  36.877 +\url{http://myhostname/~myuser/hgwebdir.cgi/this/repo}.
  36.878 +
  36.879 +Si reemplazamos \dirname{/mi/ruta} en el lado izquierdo de este
  36.880 +ejemplo con \dirname{/mi}, \sfilename{hgwebdir.cgi} eliminará solamente
  36.881 +\dirname{/mi} del nombre del repositorio, y nos ofrecerá la ruta
  36.882 +virtual \dirname{ruta/este/repo} en lugar de \dirname{este/repo}.
  36.883 +
  36.884 +El guión \sfilename{hgwebdir.cgi} buscará recursivamente en cada
  36.885 +directorio listado en la sección \texttt{collections} de su fichero de
  36.886 +configuración, pero \texttt{no} hará el recorrido recursivo dentro de
  36.887 +los repositorios que encuentre.
  36.888 +
  36.889 +El mecanismo de \texttt{collections} permite publicar fácilmente
  36.890 +repositorios de una forma ``hacer y olvidar''.  Solamente requiere
  36.891 +configurar el guión CGI y el fichero de configuración una vez.
  36.892 +Después de eso puede publicar y sacar de publicación un repositorio en
  36.893 +cualquier momento incluyéndolo o excluyéndolo de la jerarquía de
  36.894 +directorios en la cual le haya indicado a \sfilename{hgwebdir.cgi} que
  36.895 +mirase.
  36.896 +
  36.897 +\subsubsection{Especificación explícita de los repositorios a publicar}
  36.898 +
  36.899 +Además del mecanismo \texttt{collections}, el guión
  36.900 +\sfilename{hgwebdir.cgi} le permite publicar una lista específica de
  36.901 +repositorios.  Para hacerlo, cree una sección \texttt{paths}, con los
  36.902 +contenidos de la siguiente forma:
  36.903 +\begin{codesample2}
  36.904 +  [paths]
  36.905 +  repo1 = /mi/ruta/a/un/repo
  36.906 +  repo2 = /ruta/a/otro/repo
  36.907 +\end{codesample2}
  36.908 +En este caso, la ruta virtual (el componente que aparecerá en el URL)
  36.909 +está en el lado derecho de cada definición, mientras que la ruta al
  36.910 +repositorio está a la derecha.  Note que no tiene que haber relación
  36.911 +alguna entre la ruta virtual que elija y el lugar del repositorio en
  36.912 +su sistema de ficheros.
  36.913 +
  36.914 +Si lo desea, puede usar los dos mecanismos \texttt{collections} y
  36.915 +\texttt{paths} simultáneamente en un sólo fichero de configuración.
  36.916 +
  36.917 +\begin{note}
  36.918 +  Si varios repositorios tienen la misma ruta virtual,
  36.919 +  \sfilename{hgwebdir.cgi} no reportará error.  Pero se comportará
  36.920 +  impredeciblemente.
  36.921 +\end{note}
  36.922 +
  36.923 +\subsection{Descarga de ficheros fuente}
  36.924 +
  36.925 +La interfaz web de Mercurial permite a los usuarios descargar
  36.926 +un conjunto de cualquier revisión.  Este fichero contendrá una réplica
  36.927 +del directorio de trabajo en la revisión en cuestión, pero no
  36.928 +contendrá una copia de los datos del repositorio.
  36.929 +
  36.930 +De forma predeterminada esta característica no está habilitada.  Para
  36.931 +lograrlo adicione un \rcitem{web}{allow\_archive} a la sección \rcsection{web}
  36.932 +de su fichero \hgrc.
  36.933 +
  36.934 +\subsection{Opciones de configuración en Web}
  36.935 +
  36.936 +Las interfaces web de Mercurial (la orden \hgcmd{serve}, y los guiones
  36.937 +\sfilename{hgweb.cgi} y \sfilename{hgwebdir.cgi}) tienen varias
  36.938 +opciones de configuración para establecer. Todas ellas en la sección
  36.939 +\rcsection{web}.
  36.940 +\begin{itemize}
  36.941 +\item[\rcitem{web}{allow\_archive}] Determina cuáles tipos de ficheros
  36.942 +  de descarga soportará Mercurial.  Si habilita esta característica,
  36.943 +  los usuarios de la interfaz web podrán descargar una copia de la
  36.944 +  revisión del repositorio que estén viendo. Para activar la
  36.945 +  característica de descarga de fichero, el valor tendrá una secuencia
  36.946 +  de palabras extraídas de la lista de abajo.
  36.947 +  \begin{itemize}
  36.948 +  \item[\texttt{bz2}] Un fichero \command{tar} con el método de
  36.949 +    compresión \texttt{bzip2}.  Tiene la mejor tasa de compresión,
  36.950 +    pero usa más tiempo de procesamiento en el servidor.
  36.951 +  \item[\texttt{gz}] Un fichero \command{tar}, comprimido con
  36.952 +    \texttt{gzip}.
  36.953 +  \item[\texttt{zip}] Un fichero \command{zip}, comprimido con LZW.
  36.954 +    Este formato posee la peor tasa de compresión, pero es muy usado en
  36.955 +    el mundo Windows.
  36.956 +  \end{itemize}
  36.957 +  Si da una lista vacía o no tiene la entrada
  36.958 +  \rcitem{web}{allow\_archive}, esta característica se deshabilitará.
  36.959 +  A continuación un ejemplo de cómo habilitar los tres formatos soportados.
  36.960 +  \begin{codesample4}
  36.961 +    [web]
  36.962 +    allow_archive = bz2 gz zip
  36.963 +  \end{codesample4}
  36.964 +\item[\rcitem{web}{allowpull}] Booleano.  Determina si la interfaz web
  36.965 +  permite a los usuarios remotos emplear \hgcmd{pull} y \hgcmd{clone}
  36.966 +  sobre el repositorio~HTTP.  Si se coloca \texttt{no} o
  36.967 +  \texttt{false}, solamente la porción de los procesos
  36.968 +  ``orientados-a-humanos'' se habilita de la interfaz web.
  36.969 +\item[\rcitem{web}{contact}] Cadena.  Una cadena en forma libre (pero
  36.970 +  preferiblemente corta) que identifica a la persona o grupo a cargo
  36.971 +  del repositorio.  Usualmente contiene el nombre y la dirección de
  36.972 +  correo electrónico de una persona o de una lista de correo.  Aveces
  36.973 +  tiene sentido colocar esta opción en el fichero \sfilename{.hg/hgrc}
  36.974 +  del repositorio, pero en otras oportunidades en el \hgrc\ global si
  36.975 +  todos los repositorios tienen un único mantenedor.
  36.976 +\item[\rcitem{web}{maxchanges}] Entero.  La cantidad máxima de
  36.977 +  conjuntos de cambios a mostrar de forma predeterminada en cada página.
  36.978 +\item[\rcitem{web}{maxfiles}] Entero.  La cantidad máxima
  36.979 +  predeterminada de ficheros modificados a desplegar en una página.
  36.980 +\item[\rcitem{web}{stripes}] Entero.  Si la interfaz web despliega
  36.981 +  ``franjas'' para facilitar la visualización alineada de filas cuando
  36.982 +  se ve una tabla, este valor controla la cantidad de filas en cada
  36.983 +  franja.
  36.984 +\item[\rcitem{web}{style}] Controla la plantilla que Mercurial usa para
  36.985 +  desplegar la interfaz web.  Mercurial viene con dos plantillas web,
  36.986 +  llamadas \texttt{default} y \texttt{gitweb} (La primera es
  36.987 +  visualmente más atractiva).  Puede especificar una plantilla propia;
  36.988 +  consulte el capítulo~\ref{chap:template}.  A continuación mostramos
  36.989 +  cómo habilitar el estilo \texttt{gitweb}.
  36.990 +  \begin{codesample4}
  36.991 +    [web]
  36.992 +    style = gitweb
  36.993 +  \end{codesample4}
  36.994 +\item[\rcitem{web}{templates}] Ruta.  Directorio en el que se buscarán
  36.995 +  los ficheros plantilla.  De forma predeterminada, busca en el
  36.996 +  directorio en el cual fue instalado.
  36.997 +\end{itemize}
  36.998 +Si usa \sfilename{hgwebdir.cgi}, puede añadir otras opciones de
  36.999 +configuración en una sección \section{web} del fichero
 36.1000 +\sfilename{hgweb.config} en lugar del fichero \hgrc\, si lo considera
 36.1001 +más conveniente.  Estas opciones son \rcitem{web}{motd} y
 36.1002 +\rcitem{web}{style}.
 36.1003 +
 36.1004 +\subsubsection{Opciones específicas para repositorios individuales}
 36.1005 +
 36.1006 +Ciertas opciones de configuración de \rcsection{web} deben estar
 36.1007 +ubicadas en el \sfilename{.hg/hgrc} de un repositorio en lugar del
 36.1008 +fichero del usuario o el \hgrc global.
 36.1009 +\begin{itemize}
 36.1010 +\item[\rcitem{web}{description}] Cadena.  Una cadena de forma
 36.1011 +  libre (preferiblemente corta) que describa los contenidos o el
 36.1012 +  propósito del repositorio.
 36.1013 +\item[\rcitem{web}{name}] Cadena.  El nombre para visualizar en la
 36.1014 +  interfaz web del repositorio. Sustituye el nombre predeterminado, el
 36.1015 +  cual es el último componente de la ruta del repositorio.
 36.1016 +\end{itemize}
 36.1017 +
 36.1018 +\subsubsection{Opciones específicas a la orden \hgcmd{serve}}
 36.1019 +
 36.1020 +Algunas opciones en la sección \rcsection{web} de un fichero \hgrc\
 36.1021 +son de uso exclusivo para la orden \hgcmd{serve}.
 36.1022 +\begin{itemize}
 36.1023 +\item[\rcitem{web}{accesslog}] Ruta.  El nombre del fichero en el cual
 36.1024 +  se escribe la bitácora de acceso.  En principio, la orden
 36.1025 +  \hgcmd{serve} escribe esta información a la salida estándar, no a un
 36.1026 +  fichero. Las líneas de la bitácora se escriben en un formato de
 36.1027 +  fichero ``combinado'' estándar, usado por casi todos los servidores
 36.1028 +  web.
 36.1029 +\item[\rcitem{web}{address}] Cadena.  La dirección local en la cual el
 36.1030 +  servidor debe escuchar peticiones entrantes.  En principio, el
 36.1031 +  servidor escucha en todas las direcciones.
 36.1032 +\item[\rcitem{web}{errorlog}] Ruta.  El nombre de un fichero en el
 36.1033 +  cual escribir la bitácora de error.  En principio, la orden
 36.1034 +  \hgcmd{serve} escribe esta información en la salida de error
 36.1035 +  estándar, no a un fichero.
 36.1036 +\item[\rcitem{web}{ipv6}] Booleano.  Si se usa o no el protocolo
 36.1037 +  IPv6. En principio, IPv6 no se usa.
 36.1038 +\item[\rcitem{web}{port}] Entero.  El número del puerto~TCP en el cuál
 36.1039 +  el servidor escuchará.  El puerto predeterminado es el~8000.
 36.1040 +\end{itemize}
 36.1041 +
 36.1042 +\subsubsection{Elegir el fichero \hgrc\ correcto para las
 36.1043 +  configuraciones de \rcsection{web}}
 36.1044 +
 36.1045 +Es importante recordar que un servidor web como Apache o
 36.1046 +\texttt{lighttpd} se ejecutarán bajo el usuario~ID que generalmente no
 36.1047 +es el suyo  Los guiones CGI ejecutados por su servidor, tales como
 36.1048 +\sfilename{hgweb.cgi}, se ejecutarán también con el usuario~ID.
 36.1049 +
 36.1050 +Si añade opciones \rcsection{web} a su fichero personal \hgrc\, Los
 36.1051 +guiones CGI no leerán tal fichero \hgrc\.  Tales configuraciones
 36.1052 +solamente afectarán el comportamiento de la orden \hgcmd{serve} cuando
 36.1053 +usted lo ejecuta.  Para logar que los guiones CGI vean sus
 36.1054 +configuraciones, o bien cree un fichero \hgrc\ en el directorio hogar
 36.1055 +del usuario ID que ejecuta su servidor web, o añada tales
 36.1056 +configuraciones al fichero global \hgrc.
 36.1057 +
 36.1058 +
 36.1059 +%%% Local Variables: 
 36.1060 +%%% mode: latex
 36.1061 +%%% TeX-master: "00book"
 36.1062 +%%% End: 

    37.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    37.2 +++ b/es/concepts.tex	Thu Jan 29 22:00:07 2009 -0800
    37.3 @@ -0,0 +1,650 @@
    37.4 +\chapter{Tras bambalinas}
    37.5 +\label{chap:concepts}
    37.6 +
    37.7 +A diferencia de varios sistemas de control de revisiones, los
    37.8 +conceptos en los que se fundamenta Mercurial son lo suficientemente
    37.9 +simples como para entender fácilmente cómo funciona el software. 
   37.10 +Saber esto no es necesario, pero considero útil tener un ``modelo
   37.11 +mental'' de qué es lo que sucede.
   37.12 +
   37.13 +Comprender esto me da la confianza de que Mercurial ha sido
   37.14 +cuidadosamente diseñado para ser tanto \emph{seguro} como
   37.15 +\emph{eficiente}.  Y tal vez con la misma importancia, si es fácil
   37.16 +para mí hacerme a una idea adecuada de qué está haciendo el software
   37.17 +cuando llevo a cabo una tarea relacionada con control de revisiones,
   37.18 +es menos probable que me sosprenda su comportamiento.
   37.19 +
   37.20 +En este capítulo, cubriremos inicialmente los conceptos centrales
   37.21 +del diseño de Mercurial, y luego discutiremos algunos detalles
   37.22 +interesantes de su implementación.
   37.23 +
   37.24 +\section{Registro del historial de Mercurial}
   37.25 +
   37.26 +\subsection{Seguir el historial de un único fichero}
   37.27 +
   37.28 +Cuando Mercurial sigue las modificaciones a un fichero, guarda el
   37.29 +historial de dicho fichero en un objeto de metadatos llamado
   37.30 +\emph{filelog}\ndt{Fichero de registro}.  Cada entrada en el fichero
   37.31 +de registro contiene suficiente información para reconstruir una
   37.32 +revisión del fichero que se está siguiendo. Los ficheros de registro
   37.33 +son almacenados como ficheros el el directorio
   37.34 +\sdirname{.hg/store/data}. Un fichero de registro contiene dos tipos
   37.35 +de información: datos de revisiones, y un índice para ayudar a
   37.36 +Mercurial a buscar revisiones eficientemente.
   37.37 +
   37.38 +El fichero de registro de un fichero grande, o con un historial muy
   37.39 +largo, es guardado como ficheros separados para datos (sufijo
   37.40 +``\texttt{.d}'') y para el índice (sufijo ``\texttt{.i}''). Para
   37.41 +ficheros pequeños con un historial pequeño, los datos de revisiones y
   37.42 +el índice son combinados en un único fichero ``\texttt{.i}''. La
   37.43 +correspondencia entre un fichero en el directorio de trabajo y el
   37.44 +fichero de registro que hace seguimiento a su historial en el
   37.45 +repositorio se ilustra en la figura~\ref{fig:concepts:filelog}.
   37.46 +
   37.47 +\begin{figure}[ht]
   37.48 +  \centering
   37.49 +  \grafix{filelog}
   37.50 +  \caption{Relación entre ficheros en el directorio de trabajo y
   37.51 +  ficheros de registro en el repositorio}
   37.52 +  \label{fig:concepts:filelog}
   37.53 +\end{figure}
   37.54 +
   37.55 +\subsection{Administración de ficheros monitoreados}
   37.56 +
   37.57 +Mercurial usa una estructura llamada \emph{manifiesto} para
   37.58 +% TODO collect together => centralizar
   37.59 +centralizar la información que maneja acerca de los ficheros que
   37.60 +monitorea. Cada entrada en el manifiesto contiene información acerca
   37.61 +de los ficheros involucrados en un único conjunto de cambios. Una
   37.62 +entrada registra qué ficheros están presentes en el conjunto de
   37.63 +cambios, la revisión de cada fichero, y otros cuantos metadatos del
   37.64 +mismo.
   37.65 +
   37.66 +\subsection{Registro de información del conjunto de cambios}
   37.67 +
   37.68 +La \emph{bitácora de cambios} contiene información acerca de cada
   37.69 +conjunto de cambios. Cada revisión indica quién consignó un cambio, el
   37.70 +comentario para el conjunto de cambios, otros datos relacionados con
   37.71 +el conjunto de cambios, y la revisión del manifiesto a usar.
   37.72 +
   37.73 +\subsection{Relaciones entre revisiones}
   37.74 +
   37.75 +Dentro de una bitácora de cambios, un manifiesto, o un fichero de
   37.76 +registro, cada revisión conserva un apuntador a su padre inmediato
   37.77 +(o sus dos padres, si es la revisión de una fusión). Como menciońe
   37.78 +anteriormente, también hay relaciones entre revisiones \emph{a través}
   37.79 +de estas estructuras, y tienen naturaleza jerárquica.
   37.80 +
   37.81 +Por cada conjunto de cambios en un repositorio, hay exactamente una
   37.82 +revisión almacenada en la bitácora de cambios. Cada revisión de la
   37.83 +bitácora de cambios contiene un apuntador a una única revisión del
   37.84 +manifiesto. Una revisión del manifiesto almacena un apuntador a una
   37.85 +única revisión de cada fichero de registro al que se le hacía
   37.86 +seguimiento cuando fue creado el conjunto de cambios. Estas relaciones
   37.87 +se ilustran en la figura~\ref{fig:concepts:metadata}.
   37.88 +
   37.89 +\begin{figure}[ht]
   37.90 +  \centering
   37.91 +  \grafix{metadata}
   37.92 +  \caption{Relaciones entre metadatos}
   37.93 +  \label{fig:concepts:metadata}
   37.94 +\end{figure}
   37.95 +
   37.96 +Como lo muestra la figura, \emph{no} hay una relación ``uno a uno''
   37.97 +entre las revisiones en el conjunto de cambios, el manifiesto, o el
   37.98 +fichero de registro. Si el manifiesto no ha sido modificado de un
   37.99 +conjunto de cambios a otro, las entradas en la bitácora de cambios
  37.100 +para esos conjuntos de cambios apuntarán a la misma revisión del
  37.101 +manifiesto. Si un fichero monitoreado por Mercurial no sufre ningún
  37.102 +cambio de un conjunto de cambios a otro, la entrada para dicho fichero
  37.103 +en las dos revisiones del manifiesto apuntará a la misma revisión de
  37.104 +su fichero de registro.
  37.105 +
  37.106 +\section{Almacenamiento seguro y eficiente}
  37.107 +
  37.108 +La base común de las bitácoras de cambios, los manifiestos, y los
  37.109 +ficheros de registros es provista por una única estructura llamada el
  37.110 +\emph{revlog}\ndt{Contracción de \emph{revision log}, registro de
  37.111 +revisión.}.
  37.112 +
  37.113 +\subsection{Almacenamiento eficiente}
  37.114 +
  37.115 +El revlog provee almacenamiento eficiente de revisiones por medio del
  37.116 +mecanismo de \emph{deltas}\ndt{Diferencias.}.  En vez de almacenar una
  37.117 +copia completa del fichero por cada revisión, almacena los cambios
  37.118 +necesarios para transformar una revisión anterior en la nueva
  37.119 +revisión. Para muchos tipos de fichero, estos deltas son típicamente
  37.120 +de una fracción porcentual del tamaño de una copia completa del
  37.121 +fichero.
  37.122 +
  37.123 +Algunos sistemas de control de revisiones obsoletos sólo pueden
  37.124 +manipular deltas de ficheros de texto plano. Ellos o bien almacenan
  37.125 +los ficheros binarios como instantáneas completas, o codificados en
  37.126 +alguna representación de texto plano adecuada, y ambas alternativas
  37.127 +son enfoques que desperdician bastantes recursos. Mercurial puede
  37.128 +manejar deltas de ficheros con contenido binario arbitrario; no
  37.129 +necesita tratar el texto plano como un caso especial.
  37.130 +
  37.131 +\subsection{Operación segura}
  37.132 +\label{sec:concepts:txn}
  37.133 +
  37.134 +Mercurial sólo \emph{añade} datos al final de los ficheros de revlog. Nunca
  37.135 +modifica ninguna sección de un fichero una vez ha sido escrita. Esto es más
  37.136 +robusto y eficiente que otros esquemas que requieren modificar o reescribir
  37.137 +datos.
  37.138 +
  37.139 +Adicionalmente, Mercurial trata cada escritura como parte de una
  37.140 +\emph{transacción}, que puede cubrir varios ficheros. Una transacción es
  37.141 +\emph{atómica}: o bien la transacción tiene éxito y entonces todos sus efectos
  37.142 +son visibles para todos los lectores, o la operación completa es cancelada.
  37.143 +% TODO atomicidad no existe de acuerdo a DRAE, reemplazar
  37.144 +Esta garantía de atomicidad implica que, si usted está ejecutando dos copias de
  37.145 +Mercurial, donde una de ellas está leyendo datos y la otra los está escribiendo,
  37.146 +el lector nunca verá un resultado escrito parcialmente que podría confundirlo.
  37.147 +
  37.148 +El hecho de que Mercurial sólo hace adiciones a los ficheros hace más fácil
  37.149 +proveer esta garantía transaccional. A medida que sea más fácil hacer
  37.150 +operaciones como ésta, más confianza tendrá usted en que sean hechas
  37.151 +correctamente.
  37.152 +
  37.153 +\subsection{Recuperación rápida de datos}
  37.154 +
  37.155 +Mercurial evita ingeniosamente un problema común a todos los sistemas de control
  37.156 +de revisiones anteriores> el problema de la
  37.157 +\emph{recuperación\ndt{\emph{Retrieval}. Recuperación en el sentido de traer los
  37.158 +datos, o reconstruirlos a partir de otros datos, pero no debido a una falla o
  37.159 +calamidad, sino a la operación normal del sistema.} ineficiente de datos}.
  37.160 +Muchos sistemas de control de revisiones almacenan los contenidos de una
  37.161 +revisión como una serie incremental de modificaciones a una ``instantánea''.
  37.162 +Para reconstruir una versión cualquiera, primero usted debe leer la instantánea,
  37.163 +y luego cada una de las revisiones entre la instantánea y su versión objetivo.
  37.164 +Entre más largo sea el historial de un fichero, más revisiones deben ser leídas,
  37.165 +y por tanto toma más tiempo reconstruir una versión particular.
  37.166 +
  37.167 +\begin{figure}[ht]
  37.168 +  \centering
  37.169 +  \grafix{snapshot}
  37.170 +  \caption{Instantánea de un revlog, con deltas incrementales}
  37.171 +  \label{fig:concepts:snapshot}
  37.172 +\end{figure}
  37.173 +
  37.174 +La innovación que aplica Mercurial a este problema es simple pero efectiva.
  37.175 +Una vez la cantidad de información de deltas acumulada desde la última
  37.176 +instantánea excede un umbral fijado de antemano, se almacena una nueva
  37.177 +instantánea (comprimida, por supuesto), en lugar de otro delta. Esto hace
  37.178 +posible reconstruir \emph{cualquier} versión de un fichero rápidamente. Este
  37.179 +enfoque funciona tan bien que desde entonces ha sido copiado por otros sistemas
  37.180 +de control de revisiones.
  37.181 +
  37.182 +La figura~\ref{fig:concepts:snapshot} ilustra la idea. En una entrada en el
  37.183 +fichero índice de un revlog, Mercurial almacena el rango de entradas (deltas)
  37.184 +del fichero de datos que se deben leer para reconstruir una revisión en
  37.185 +particular.
  37.186 +
  37.187 +\subsubsection{Nota al margen: la influencia de la compresión de vídeo}
  37.188 +
  37.189 +Si le es familiar la compresión de vídeo, o ha mirado alguna vez una emisión de
  37.190 +TV a través de cable digital o un servicio de satélite, puede que sepa que la 
  37.191 +mayor parte de los esquemas de compresión de vídeo almacenan cada cuadro del
  37.192 +mismo como un delta contra el cuadro predecesor. Adicionalmente, estos esquemas
  37.193 +usan técnicas de compresión ``con pérdida'' para aumentar la tasa de
  37.194 +compresión, por lo que los errores visuales se acumulan a lo largo de una
  37.195 +cantidad de deltas inter-cuadros.
  37.196 +
  37.197 +Ya que existe la posibilidad de que un flujo de vídeo se ``pierda''
  37.198 +ocasionalmente debido a fallas en la señal, y para limitar la acumulación de
  37.199 +errores introducida por la compresión con pérdidas, los codificadores de vídeo
  37.200 +insertan periódicamente un cuadro completo (también llamado ``cuadro clave'') en
  37.201 +el flujo de vídeo; el siguiente delta es generado con respecto a dicho cuadro.
  37.202 +Esto quiere decir que si la señal de vídeo se interrumpe, se reanudará una vez
  37.203 +se reciba el siguiente cuadro clave. Además, la acumulación de errores de
  37.204 +codificación se reinicia con cada cuadro clave.
  37.205 +
  37.206 +\subsection{Identificación e integridad fuerte}
  37.207 +
  37.208 +Además de la información de deltas e instantáneas, una entrada en un
  37.209 +% TODO de pronto aclarar qué diablos es un hash?
  37.210 +revlog contiene un hash criptográfico de los datos que representa.
  37.211 +Esto hace difícil falsificar el contenido de una revisión, y hace
  37.212 +fácil detectar una corrupción accidental.
  37.213 +
  37.214 +Los hashes proveen más que una simple revisión de corrupción: son
  37.215 +usados como los identificadores para las revisiones. 
  37.216 +% TODO no entendí completamente la frase a continuación
  37.217 +Los hashes de
  37.218 +identificación de conjuntos de cambios que usted ve como usuario final
  37.219 +son de las revisiones de la bitácora de cambios. Aunque los ficheros
  37.220 +de registro y el manifiesto también usan hashes, Mercurial sólo los
  37.221 +usa tras bambalinas.
  37.222 +
  37.223 +Mercurial verifica que los hashes sean correctos cuando recupera
  37.224 +revisiones de ficheros y cuando jala cambios desde otro repositorio.
  37.225 +Si se encuentra un problema de integridad, Mercurial se quejará y
  37.226 +detendrá cualquier operación que esté haciendo.
  37.227 +
  37.228 +Además del efecto que tiene en la eficiencia en la recuperación, el
  37.229 +uso periódico de instantáneas de Mercurial lo hace más robusto frente
  37.230 +a la corrupción parcial de datos. Si un fichero de registro se
  37.231 +corrompe parcialmente debido a un error de hardware o del sistema, a
  37.232 +menudo es posible reconstruir algunas o la mayoría de las revisiones a
  37.233 +partir de las secciones no corrompidas del fichero de registro, tanto
  37.234 +antes como después de la sección corrompida. Esto no sería posible con
  37.235 +un sistema de almacenamiento basado únicamente en deltas.
  37.236 +
  37.237 +\section{Historial de revisiones, ramas y fusiones}
  37.238 +
  37.239 +Cada entrada en el revlog de Mercurial conoce la identidad de la
  37.240 +revisión de su ancestro inmediato, al que se conoce usualmente como su
  37.241 +\emph{padre}. De hecho, una revisión contiene sitio no sólo para un
  37.242 +padre, sino para dos. Mercurial usa un hash especial, llamado el
  37.243 +``ID nulo'', para representar la idea de ``no hay padre aquí''. Este
  37.244 +hash es simplemente una cadena de ceros.
  37.245 +
  37.246 +En la figura~\ref{fig:concepts:revlog} usted puede ver un ejemplo de
  37.247 +la estructura conceptual de un revlog. Los ficheros de registro,
  37.248 +manifiestos, y bitácoras de cambios comparten la misma estructura;
  37.249 +sólo difieren en el tipo de datos almacenados en cada delta o
  37.250 +instantánea.
  37.251 +
  37.252 +La primera revisión en un revlog (al final de la imagen) tiene como
  37.253 +padre al ID nulo, en las dos ranuras disponibles para padres. En una
  37.254 +revisión normal, la primera ranura para padres contiene el ID de la
  37.255 +revisión padre, y la segunda contiene el ID nulo, señalando así que la
  37.256 +revisión sólo tiene un padre real. Un par de revisiones que tenga el
  37.257 +mismo ID padre son ramas. Una revisión que representa una fusión entre
  37.258 +ramas tiene dos IDs de revisión normales en sus ranuras para padres.
  37.259 +
  37.260 +\begin{figure}[ht]
  37.261 +  \centering
  37.262 +  \grafix{revlog}
  37.263 +  \caption{}
  37.264 +  \label{fig:concepts:revlog}
  37.265 +\end{figure}
  37.266 +
  37.267 +\section{El directorio de trabajo}
  37.268 +
  37.269 +% TODO revisar párrafo, no me convence la traducción
  37.270 +En el directorio de trabajo, Mercurial almacena una instantánea de los
  37.271 +ficheros  del repositorio como si fueran los de un conjunto de cambios
  37.272 +particular.
  37.273 +
  37.274 +El directorio de trabajo ``sabe'' qué conjunto de cambios contiene.
  37.275 +Cuando usted actualiza el directorio de trabajo para que contenga un
  37.276 +conjunto de cambios particular, Mercurial busca la revisión adecuada
  37.277 +del manifiesto para averiguar qué ficheros estaba monitoreando cuando
  37.278 +se hizo la consignación del conjunto de cambios, y qué revisión de
  37.279 +cada fichero era la actual en ese momento. Luego de eso, recrea una
  37.280 +copia de cada uno de esos ficheros, con los mismos contenidos que
  37.281 +tenían cuando fue consignado el conjunto de cambios.
  37.282 +
  37.283 +El \emph{estado de directorio}\ndt{dirstate, en inglés en el
  37.284 +original.} contiene el conocimiento de Mercurial acerca del directorio
  37.285 +de trabajo. Allí se detalla a qué conjunto de cambios es actualizado
  37.286 +el directorio de trabajo, y todos los ficheros que Mercurial está
  37.287 +monitoreando en este directorio.
  37.288 +
  37.289 +Tal como la revisión de un revlog tiene espacio para dos padres, para
  37.290 +que pueda representar tanto una revisión normal (con un solo padre) o
  37.291 +una fusión de dos revisiones anteriores, el estado de directorio tiene
  37.292 +espacio para dos padres. Cuando usted usa el comando \hgcmd{update},
  37.293 +el conjunto de cambios al que usted se actualiza es almacenado en la
  37.294 +casilla destinada al ``primer padre'', y un ID nulo es almacenado en
  37.295 +la segunda. Cuando usted hace una fusión (\hgcmd{merge}) con otro
  37.296 +conjunto de cambios, la casilla para el primer padre permanece sin
  37.297 +cambios, y la casilla para el segundo es actualizada con el conjunto
  37.298 +de cambios con el que usted acaba de hacer la fusión. El comando
  37.299 +\hgcmd{parents} le indica cuáles son los padres del estado de
  37.300 +directorio.
  37.301 +
  37.302 +\subsection{Qué pasa en una consignación}
  37.303 +
  37.304 +El estado de directorio almacena información sobre los padres para
  37.305 +algo más que mero registro. Mercurial usa los padres del estado de
  37.306 +directorio como \emph{los padres de un nuevo conjunto de cambios}
  37.307 +cuando usted hace una consignación.
  37.308 +
  37.309 +\begin{figure}[ht]
  37.310 +  \centering
  37.311 +  \grafix{wdir}
  37.312 +  \caption{El directorio de trabajo puede tener dos padres}
  37.313 +  \label{fig:concepts:wdir}
  37.314 +\end{figure}
  37.315 +
  37.316 +La figura~\ref{fig:concepts:wdir} muestra el estado normal del
  37.317 +directorio de trabajo, que tiene un único conjunto de cambios como
  37.318 +padre. Dicho conjunto de cambios es la \emph{punta}, el conjunto de
  37.319 +cambios más reciente en el repositorio que no tiene hijos.
  37.320 +
  37.321 +\begin{figure}[ht]
  37.322 +  \centering
  37.323 +  \grafix{wdir-after-commit}
  37.324 +  \caption{El directorio de trabajo obtiene nuevos padres luego de una
  37.325 +  consignación}
  37.326 +  \label{fig:concepts:wdir-after-commit}
  37.327 +\end{figure}
  37.328 +
  37.329 +Es útil pensar en el directorio de trabajo como en ``el conjunto de
  37.330 +cambios que estoy a punto de enviar''. Cualquier fichero que usted le
  37.331 +diga a Mercurial que fue añadido, borrado, renombrado o copiado, se
  37.332 +verá reflejado en ese conjunto de cambios, como también se verán las
  37.333 +modificaciones a cualquiera de los ficheros que Mercurial ya esté
  37.334 +monitoreando; el nuevo conjunto de cambios dentrá los padres del
  37.335 +directorio de trabajo como propios.
  37.336 +
  37.337 +Luego de una consignación, Mercurial actualizará los padres del
  37.338 +directorio de trabajo, de tal manera que el primer padre sea el ID del
  37.339 +nuevo conjunto de cambios, y el segundo sea el ID nulo. Esto puede
  37.340 +verse en la figura~\ref{fig:concepts:wdir-after-commit}.  Mercurial no
  37.341 +toca ninguno de los ficheros del directorio de trabajo cuando usted
  37.342 +hace la consignación; sólo modifica el estado de directorio para
  37.343 +anotar sus nuevos padres.
  37.344 +
  37.345 +\subsection{Creación de un nuevo frente}
  37.346 +
  37.347 +Es perfectamente normal actualizar el directorio de trabajo a un
  37.348 +conjunto de cambios diferente a la punta actual. Por ejemplo, usted
  37.349 +podría desear saber en qué estado se encontraba su proyecto el martes
  37.350 +pasado, o podría estar buscando en todos los conjuntos de cambios para
  37.351 +saber cuándo se introdujo un fallo. En casos como éstos, la acción
  37.352 +natural es actualizar el directorio de trabajo al conjunto de cambios
  37.353 +de su interés, y examinar directamente los ficheros en el directorio
  37.354 +de trabajo para ver sus contenidos tal como estaban en el momento de
  37.355 +hacer la consignación. El efecto que tiene esto se muestra en la
  37.356 +figura~\ref{fig:concepts:wdir-pre-branch}.
  37.357 +
  37.358 +\begin{figure}[ht]
  37.359 +  \centering
  37.360 +  \grafix{wdir-pre-branch}
  37.361 +  \caption{El directorio de trabajo, actualizado a un conjunto de
  37.362 +  cambios anterior}
  37.363 +  \label{fig:concepts:wdir-pre-branch}
  37.364 +\end{figure}
  37.365 +
  37.366 +Una vez se ha actualizado el directorio de trabajo a un conjunto de
  37.367 +cambios anterior, qué pasa si se hacen cambios, y luego se hace una
  37.368 +consignación? Mercurial se comporta en la misma forma que describí
  37.369 +anteriormente. Los padres del directorio de trabajo se convierten en
  37.370 +los padres del nuevo conjunto de cambios. Este nuevo conjunto de
  37.371 +cambios no tiene hijos, así que se convierte en la nueva punta. Y el
  37.372 +repositorio tiene ahora dos conjuntos de cambios que no tienen hijos;
  37.373 +a éstos los llamamos \emph{frentes}. Usted puede apreciar la
  37.374 +estructura que esto crea en la figura~\ref{fig:concepts:wdir-branch}.
  37.375 +
  37.376 +\begin{figure}[ht]
  37.377 +  \centering
  37.378 +  \grafix{wdir-branch}
  37.379 +  \caption{Después de una consignación hecha mientras se usaba un
  37.380 +  conjunto de cambios anterior}
  37.381 +  \label{fig:concepts:wdir-branch}
  37.382 +\end{figure}
  37.383 +
  37.384 +\begin{note}
  37.385 +    Si usted es nuevo en Mercurial, debería tener en mente un
  37.386 +    ``error'' común, que es usar el comando \hgcmd{pull} sin ninguna
  37.387 +    opción. Por defecto, el comando \hgcmd{pull} \emph{no} actualiza
  37.388 +    el directorio de trabajo, así que usted termina trayendo nuevos
  37.389 +    conjuntos de cambios a su repositorio, pero el directorio de
  37.390 +    trabajo sigue usando el mismo conjunto de cambios que tenía antes
  37.391 +    de jalar. Si usted hace algunos cambios, y luego hace una
  37.392 +    consignación, estará creando un nuevo frente, porque su directorio
  37.393 +    de trabajo no es sincronizado a cualquiera que sea la nueva punta.
  37.394 +
  37.395 +    Pongo la palabra ``error'' en comillas porque todo lo que usted
  37.396 +    debe hacer para rectificar la situación es hacer una fusión
  37.397 +    (\hgcmd{merge}), y luego una consignación (\hgcmd{commit}). En
  37.398 +    otras palabras, esto casi nunca tiene consecuencias negativas;
  37.399 +    sólo sorprende a la gente. Discutiré otras formas de evitar este
  37.400 +    comportamiento, y porqué Mercurial se comporta de esta forma,
  37.401 +    inicialmente sorprendente, más adelante.
  37.402 +\end{note}
  37.403 +
  37.404 +\subsection{Fusión de frentes}
  37.405 +
  37.406 +Cuando usted ejecuta el comando \hgcmd{merge}, Mercurial deja el
  37.407 +primer padre del directorio de trabajo intacto, y escribe como segundo
  37.408 +padre el conjunto de cambios contra el cual usted está haciendo la
  37.409 +fusión, como se muestra en la figura~\ref{fig:concepts:wdir-merge}.
  37.410 +
  37.411 +\begin{figure}[ht]
  37.412 +  \centering
  37.413 +  \grafix{wdir-merge}
  37.414 +  \caption{Fusión de dos frentes}
  37.415 +  \label{fig:concepts:wdir-merge}
  37.416 +\end{figure}
  37.417 +
  37.418 +Mercurial también debe modificar el directorio de trabajo, para
  37.419 +fusionar los ficheros que él monitorea en los dos conjuntos de
  37.420 +cambios. Con algunas simplificaciones, el proceso es el siguiente, por
  37.421 +cada fichero en los manifiestos de ambos conjuntos de cambios.
  37.422 +\begin{itemize}
  37.423 +\item Si ningún conjunto de cambios ha modificado un fichero, no se
  37.424 +    hace nada con el mismo.
  37.425 +\item Si un conjunto de cambios ha modificado un fichero, y el otro no
  37.426 +    lo ha hecho, se crea una copia del fichero con las modificaciones
  37.427 +    pertinentes en el directorio de trabajo.
  37.428 +\item Si un conjunto de cambios borra un fichero, y el otro no lo ha
  37.429 +    hecho (o también lo borró), se borra dicho fichero del directorio
  37.430 +    de trabajo.
  37.431 +\item Si un conjunto de cambios ha borrado un fichero, pero el otro lo ha
  37.432 +    modificado, se le pregunta al usuario qué hacer: conservar el
  37.433 +    fichero modificado, o borrarlo?
  37.434 +\item Si ambos conjuntos de cambios han modificado un fichero, se
  37.435 +    invoca el programa externo de fusión para definir el nuevo
  37.436 +    contenido del fichero fusionado. Esto puede requerir interacción
  37.437 +    directa de parte del usuario.
  37.438 +\item Si un conjunto de cambios ha modificado un fichero, y el otro ha
  37.439 +    renombrado o copiado el mismo, asegurarse de que los cambios sigan
  37.440 +    al nuevo nombre de fichero.
  37.441 +\end{itemize}
  37.442 +Hay más detalles---hacer una fusión tiene una gran cantidad de casos
  37.443 +especiales---pero éstas son las elecciones más comunes que se ven
  37.444 +involucradas en una fusión. Como usted puede ver, muchos de los casos
  37.445 +son completamente automáticos, y de hecho la mayoría de las fusiones
  37.446 +terminan automáticamente, sin requerir la interacción del usuario para
  37.447 +resolver ningún conflicto.
  37.448 +
  37.449 +Cuando considere qué pasa cuando usted hace una consignación después
  37.450 +de una fusión, de nuevo el directorio de trabajo es ``el conjunto de
  37.451 +cambios que estoy a punto de consignar''. Una vez termina su trabajo
  37.452 +el comando \hgcmd{merge}, el directorio de trabajo tiene dos padre;
  37.453 +éstos se convertirán en los padres del nuevo conjunto de cambios.
  37.454 +
  37.455 +Mercurial le permite hacer múltiples fusiones, pero usted debe
  37.456 +consignar los resultados de cada fusión sucesivamente. Esto es
  37.457 +necesario porque Mercurial sólo monitorea dos padres, tanto para las
  37.458 +revisiones como para los directorios de trabajo. Aunque técnicamente
  37.459 +es posible fusionar varios conjuntos de trabajo en una sola operación,
  37.460 +la posibilidad de confundir al usuario y crear un desorden terrible en
  37.461 +la fusión se hace incontenible de inmediato.
  37.462 +
  37.463 +\section{Otras características de diseño interesantes}
  37.464 +
  37.465 +En las secciones anteriores, he tratado de resaltar algunos de los
  37.466 +aspectos más importantes del diseño de Mercurial, para mostrar que se
  37.467 +presta gran cuidado y atención a la confiabilidad y el desempeño. Sin
  37.468 +embargo, la atención a los detalles no para ahí. Hay una cantidad de
  37.469 +aspectos de la construcción de Mercurial que encuentro interesantes
  37.470 +personalmente. Detallaré unos cuantos de ellos aquí, aparte de los
  37.471 +elementos ``importantes'' de arriba, para que, si usted está
  37.472 +% TODO the amount of thinking => (la cantidad de) esfuerzo mental
  37.473 +interesado, pueda obetener una idea mejor de la cantidad de esfuerzo
  37.474 +mental invertido en el diseño de un sistema bien diseñado.
  37.475 +
  37.476 +
  37.477 +\subsection{Compresión ingeniosa}
  37.478 +
  37.479 +Cuando es adecuado, Mercurial almacenará tanto las instantáneas como
  37.480 +los deltas en formato comprimido. Lo hace \emph{tratando} siempre de
  37.481 +comprimir una instantánea o delta, y conservando la versión comprimida
  37.482 +sólo si es más pequeña que la versión sin compresión.
  37.483 +
  37.484 +Esto implica que Mercurial hace ``lo correcto'' cuando almacena un
  37.485 +fichero cuyo formato original está comprimido, como un fichero
  37.486 +\texttt{zip} o una imagen JPEG.  Cuando estos tipos de ficheros son
  37.487 +comprimidos por segunda vez, el fichero resultante usualmente es más
  37.488 +grande que la versión comprimida una sola vez, por lo que Mercurial
  37.489 +almacenará el fichero \texttt{zip} o JPEG original.
  37.490 +
  37.491 +Los deltas entre revisiones de un fichero comprimido usualmente son
  37.492 +más grandes que las instantáneas del mismo fichero, y Mercurial de
  37.493 +nuevo hace ``lo correcto'' en estos casos. Él encuentra que dicho
  37.494 +delta excede el umbral respecto al cual se debería almacenar una
  37.495 +instantánea completa del fichero, así que almacena la instantánea,
  37.496 +ahorrando espacio de nuevo respecto al enfoque simplista de usar
  37.497 +únicamente deltas.
  37.498 +
  37.499 +\subsubsection{Recompresión de red}
  37.500 +
  37.501 +Cuando almacena las revisiones en disco, Mercurial usa el algoritmo de
  37.502 +compresión ``deflación'' (el mismo usado en el popular formato de
  37.503 +fichero \texttt{zip}), que provee una buena velocidad con una tasa de
  37.504 +compresión respetable. Sin embargo, cuando se transmiten datos de
  37.505 +revisiones a través de una conexión de red, Mercurial descomprime los
  37.506 +datos comprimidos de las revisiones.
  37.507 +
  37.508 +Si la conexión es hecha a través de HTTP, Mercurial recomprime el
  37.509 +flujo completo de datos usando un algoritmo de compresión que brinda
  37.510 +una mejor tasa de compresión (el algoritmo Burrows-Wheeler del
  37.511 +ampliamente usado paquete de compresión \texttt{bzip2}). Esta
  37.512 +combinación de algoritmo y compresión del flujo completo de datos
  37.513 +(en vez de una revisión a la vez) reduce sustancialmente la cantidad
  37.514 +de bytes a transferir, brindando así un mejor desempeño de red sobre
  37.515 +casi todo tipo de redes.
  37.516 +
  37.517 +(Si la conexión se hace sobre \command{ssh}, Mercurial \emph{no}
  37.518 +recomprmime el flujo, porque \command{ssh} puede hacer esto por sí
  37.519 +mismo.)
  37.520 +
  37.521 +\subsection{Reordenado de lectura/escritura y atomicidad}
  37.522 +
  37.523 +Añadir datos al final de un fichero no es todo lo que hace falta para
  37.524 +garantizar que un lector no verá una escritura parcial. Si recuerda la
  37.525 +figura~\ref{fig:concepts:metadata}, las revisiones en la bitácora de
  37.526 +cambios apuntan a revisiones en el manifiesto, y las revisiones en el
  37.527 +manifiesto apuntan a revisiones en ficheros de registro. Esta
  37.528 +jerarquía es deliberada.
  37.529 +
  37.530 +Un escritor inicia una transacción al escribir los datos del ficheros
  37.531 +del fichero de registro y el manifiesto, y no escribe nada en la
  37.532 +bitácora de cambios hasta que dichas escrituras hayan terminado. Un
  37.533 +lector empieza leyendo datos de la bitácora de cambios, luego del
  37.534 +manifiesto, y finalmente del fichero de registro.
  37.535 +
  37.536 +%TODO revisar párrafo completo, no me gusta el resultado
  37.537 +Como el escritor siempre termina de escribir los datos en el fichero
  37.538 +de registro y en el manifiesto antes de escribir a la bitácora de
  37.539 +cambios, un lector nunca verá un apuntador a una versión parcialmente
  37.540 +escrita de revisiones del manifiesto desde la bitácora de cambios, y
  37.541 +nunca leerá un apuntador a una revisión parcialmente escrita del
  37.542 +fichero de registro desde el manifiesto.
  37.543 +
  37.544 +\subsection{Acceso concurrente}
  37.545 +
  37.546 +El reordenado de lectura/escritura y la atomicidad garantizan que
  37.547 +Mercurial nunca necesita \emph{bloquear} un repositorio cuando está
  37.548 +leyendo datos, aún si se está escribiendo al repositorio mientras se
  37.549 +hace la lectura. Esto tiene un gran efecto en la escalabilidad; usted
  37.550 +puede tener cualquier cantidad de procesos Mercurial leyendo datos de
  37.551 +un repositorio de manera segura al mismo tiempo, sin importar si se
  37.552 +está escribiendo al mismo o no.
  37.553 +
  37.554 +La naturaleza carente de bloqueos de la lectura significa que si usted
  37.555 +está compartiendo un repositorio en un sistema multiusuario, no
  37.556 +necesita dar a los usuarios locales permisos de \emph{escritura} a su
  37.557 +repositorio para que ellos puedan clonarlo o jalar cambios; sólo
  37.558 +necesitan permisos de \emph{lectura}. (Esta \emph{no} es una
  37.559 +%TODO signo de admiración de apertura
  37.560 +característica común entre los sistemas de control de revisiones, así
  37.561 +que no la dé por hecha! Muchos de ellos requieren que los lectores
  37.562 +sean capaces de bloquear el repositorio antes de poder leerlo, y esto
  37.563 +requiere acceso de escritura en al menos un directorio, lo que por
  37.564 +supuesto se convierte en una fuente de todo tipo de problemas
  37.565 +administrativos y de seguridad bastante molestos.)
  37.566 +
  37.567 +Mercurial usar bloqueos para asegurarse de que sólo un proceso pueda
  37.568 +escribir a un repositorio al mismo tiempo (el mecanismo de bloqueo es
  37.569 +seguro incluso sobre sistemas de ficheros notoriamente hostiles al
  37.570 +bloqueo, como NFS). Si un repositorio está bloqueado, los escritores
  37.571 +esperarán un buen rato para revisar si el repositorio ya ha sido
  37.572 +desbloqueado, pero si el repositorio sique bloqueado por mucho tiempo,
  37.573 +el proceso que intenta escribir fallará por tiempo de espera máximo.
  37.574 +Esto significa que sus guiones automáticos diarios no se quedarán
  37.575 +esperando para siempre, apilándose si el sistema se cayó sin que nadie
  37.576 +se diera cuenta, por ejemplo. (Sí, el tiempo de espera máximo es
  37.577 +configurable, de cero a infinito).
  37.578 +
  37.579 +
  37.580 +\subsubsection{Acceso seguro al estado de directorio}
  37.581 +
  37.582 +Al igual que con los datos de revisión, Mercurial no requiere un
  37.583 +bloqueo para leer el fichero de estado de directorio; sí se usa un
  37.584 +bloqueo para escribir a él. Para evitar la posibilidad de leer una
  37.585 +copia parcialmente escrita del fichero de estado de directorio,
  37.586 +Mercurial escribe a un fichero con un nombre único en el mismo
  37.587 +directorio del fichero de estado de directorio, y luego renombra
  37.588 +atómicamente este fichero temporal a \filename{dirstate}\ndt{Estado de
  37.589 +directorio.}. Así se garantiza que el fichero llamado
  37.590 +\filename{dirstate} esté completo, y no parcialmente escrito.
  37.591 +
  37.592 +\subsection{Evitar movimientos de brazo}
  37.593 +
  37.594 +Un aspecto crítico para el desempeño de Mercurial es evitar los
  37.595 +movimientos del brazo de lectura del disco duro, ya que cualquier
  37.596 +movimiento de brazo es mucho más costoso que incluso una operación de
  37.597 +lectura relativamente grande.
  37.598 +
  37.599 +Es por esto que, por ejemplo, el estado de directorio es almacenado
  37.600 +como un solo fichero. Si hubiera un estado de directorio por cada
  37.601 +directorio que Mercurial monitorea, el disco haría un movimiento de
  37.602 +brazo por cada directorio. En cambio, Mercurial lee el estado de
  37.603 +directorio completo en un solo paso.
  37.604 +
  37.605 +Mercurial también usa un esquema de ``copiar al escribir'' cuando
  37.606 +clona un repositorio en un mismo medio de almacenamiento local. En vez
  37.607 +de copiar cada fichero de revlog del repositorio viejo al nuevo, se
  37.608 +crea un ``enlace duro'', que es una manera sucinta de decir
  37.609 +``estos dos nombres apuntan al mismo fichero''. Cuando Mercurial está
  37.610 +a punto de escribir a uno de los ficheros de revlog, revisa si la
  37.611 +cantidad de nombres apuntando al fichero es de más de uno. Si lo es,
  37.612 +más de un repositorio está usando el fichero, así que Mercurial hace
  37.613 +una nueva copia del fichero, privada para este repositorio.
  37.614 +
  37.615 +Algunos desarrolladores de control de revisiones han indicado que la
  37.616 +idea de hacer una copia privada completa de un fichero no es eficiente
  37.617 +desde el punto de vista de almacenamiento. Aunque esto es cierto, el
  37.618 +almacenamiento es barato, y este método brinda el máximo rendimiento
  37.619 +al tiempo que delega la mayor parte del trabajo de manejo de ficheros
  37.620 +al sistema operativo. Un esquema alternativo seguramente reduciría el
  37.621 +desempeño y aumentaría la complejidad del software, cada uno de los
  37.622 +cuales es mucho más importante para la ``sensación'' que se tiene del
  37.623 +software en el trabajo día a día.
  37.624 +
  37.625 +\subsection{Otros contenidos del estado de directorio}
  37.626 +
  37.627 +Debido a que Mercurial no lo fuerza a indicar si usted está
  37.628 +modificando un fichero, se usa el estado de directorio para almacenar
  37.629 +información extra para poder determinar efecientemente si usted ha
  37.630 +modificado un fichero. Por cada fichero en el directorio de trabajo,
  37.631 +se almacena el momento en que Mercurial modificó por última vez el
  37.632 +fichero, y el tamaño del fichero en ese momento.
  37.633 +
  37.634 +Cuando usted añade (\hgcmd{add}), remueve (\hgcmd{remove}), renombra
  37.635 +(\hgcmd{rename}) o copia (\hgcmd{copy}) ficheros, Mercurial actualiza
  37.636 +el estado de directorio para saber qué hacer con dichos ficheros
  37.637 +cuando usted haga la consignación.
  37.638 +
  37.639 +Cuando Mercurial está revisando el estado de los ficheros en el
  37.640 +directorio de trabajo, revisa primero la fecha de modificación del
  37.641 +fichero. Si no ha cambiado, el fichero no ha sido modificado. Si el
  37.642 +tamaño del fichero ha cambiado, el fichero ha sido modificado. Sólo en
  37.643 +el caso en que el tiempo de modificación ha cambiado, pero el tamaño
  37.644 +no, es necesario leer el contenido del fichero para revisar si ha
  37.645 +cambiado. Almacenar estos pocos datos reduce dramáticamente la
  37.646 +cantidad de datos que Mercurial debe leer, lo que brinda una mejora en
  37.647 +el rendimiento grande, comparado con otros sistemas de control de
  37.648 +revisiones.
  37.649 +
  37.650 +%%% Local Variables: 
  37.651 +%%% mode: latex
  37.652 +%%% TeX-master: "00book"
  37.653 +%%% End:

    38.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    38.2 +++ b/es/daily.tex	Thu Jan 29 22:00:07 2009 -0800
    38.3 @@ -0,0 +1,404 @@
    38.4 +\chapter{Mercurial día a día}
    38.5 +\label{chap:daily}
    38.6 +
    38.7 +\section{Cómo indicarle a Mercurial qué ficheros seguir}
    38.8 +
    38.9 +Mercurial no trabaja con ficheros en su repositorio a menos que usted
   38.10 +se lo indique explícitamente.  La orden \hgcmd{status} le mostrará
   38.11 +cuáles ficheros son desconocidos para Mercurial; se emplea un
   38.12 +``\texttt{?}'' para mostrar tales ficheros.
   38.13 +
   38.14 +Para indicarle a Mercurial que tenga en cuenta un fichero, emplee la
   38.15 +orden \hgcmd{add}. Una vez que haya adicionado el fichero, la línea
   38.16 +referente al fichero al aplicar la orden \hgcmd{status} para tal
   38.17 +fichero cambia de ``\texttt{?}'' a ``\texttt{A}''.
   38.18 +\interaction{daily.files.add}
   38.19 +
   38.20 +Después de invocar \hgcmd{commit}, los ficheros que haya adicionado
   38.21 +antes de consignar no se listarán en la salida de \hgcmd{status}.  La
   38.22 +razón para esto es que \hgcmd{status} solamente le muestra aquellos
   38.23 +ficheros ``interesantes'' ---~los que usted haya modificado o a aquellos
   38.24 +sobre los que usted haya indicado a Mercurial hacer algo--- de forma
   38.25 +predeterminada. Si tiene un repositorio que contiene miles de
   38.26 +ficheros, rara vez deseará saber cuáles de ellos están siendo
   38.27 +seguidos por Mercurial, pero que no han cambiado.  (De todas maneras,
   38.28 +puede obtener tal información; más adelante hablaremos de ello.)
   38.29 +
   38.30 +
   38.31 +Cuando usted añade un fichero, Mercurial no hace nada con él inmediatamente.
   38.32 +En cambio, tomará una instantánea del estado del fichero la próxima vez
   38.33 +que usted consigne. Continuará haciendo seguimiento a los cambios que
   38.34 +haga sobre el fichero cada vez que consigne, hasta que usted lo elimine.
   38.35 +
   38.36 +\subsection{Nombramiento explícito e implícito de ficheros}
   38.37 +
   38.38 +Mercurial tiene un comportamiento útil en el cual si a una orden,
   38.39 +le pasa el nombre de un directorio, todas las órdenes lo interpretarán como
   38.40 +``Deseo operar en cada fichero de este directorio y sus 
   38.41 +subdirectorios''.
   38.42 +\interaction{daily.files.add-dir}
   38.43 +Tenga en cuenta que en este ejemplo Mercurial imprimió los nombres de
   38.44 +los ficheros que se adicionaron, mientras que no lo hizo en el ejemplo
   38.45 +anterior cuando adicionamos el fichero con nombre \filename{a}.
   38.46 +
   38.47 +En el último caso hicimos explícito el nombre del fichero que
   38.48 +deseábamos adicionar en la línea de órdenes, y Mercurial asume en
   38.49 +tales casos que usted sabe lo que está haciendo y no imprime
   38.50 +información alguna.
   38.51 +
   38.52 +Cuando hacemos \emph{implícitos} los nombres de los ficheros dando el
   38.53 +nombre de un directorio, Mercurial efectúa el paso extra de imprimir
   38.54 +el nombre de cada fichero con el que va a hacer algo.  Esto para
   38.55 +aclarar lo que está sucediendo, y reducir en lo posible una sorpresa
   38.56 +silenciosa pero fatal.  Este comportamiento es común a la mayoría de
   38.57 +órdenes en Mercurial.
   38.58 +
   38.59 +\subsection{Nota al margen: Mercurial trata ficheros, no directorios}
   38.60 +
   38.61 +Mercurial no da seguimiento a la información de los directorios.  En
   38.62 +lugar de eso tiene en cuenta las rutas de los ficheros.  Antes  de
   38.63 +crear un fichero, primero crea todos los directorios que hagan falta
   38.64 +para completar la ruta del mismo. Después de borrar un fichero,
   38.65 +borra todos los directorios vacíos que estuvieran en la ruta del
   38.66 +fichero borrado. Suena como una diferencia trivial, pero tiene una
   38.67 +consecuencia práctica menor: no es posible representar un directorio
   38.68 +completamente vacío en Mercurial.
   38.69 +
   38.70 +Los directorios vacíos rara vez son útiles, y hay soluciones
   38.71 +alternativas no intrusivas que usted puede emplear para obtener el efecto
   38.72 +apropiado. Los desarrolladores de Mercurial pensaron que la
   38.73 +complejidad necesaria para administrar directorios vacíos no valía la
   38.74 +pena frente al beneficio limitado que esta característica podría traer.
   38.75 +
   38.76 +Si necesita un directorio vacío en su repositorio, hay algunas formas
   38.77 +de lograrlo. Una es crear un directorio, después hacer \hgcmd{add} a
   38.78 +un fichero ``oculto'' dentro de ese directorio. En sistemas tipo
   38.79 +Unix, cualquier fichero cuyo nombre comience con un punto
   38.80 +(``\texttt{.}'') es tratado como oculto por la mayoría de
   38.81 +comandos y herramientas GUI. Esta aproximación se ilustra en la figura~\ref{ex:daily:hidden}.
   38.82 +
   38.83 +\begin{figure}[ht]
   38.84 +  \interaction{daily.files.hidden}
   38.85 +  \caption{Simular un directorio vacío con un fichero oculto}
   38.86 +  \label{ex:daily:hidden}
   38.87 +\end{figure}
   38.88 +
   38.89 +Otra forma de abordar la necesidad de un directorio vacío es
   38.90 +simplemente crear uno en sus guiones de construcción antes de que lo
   38.91 +necesiten.
   38.92 +
   38.93 +\section{Cómo dejar de hacer seguimiento a un fichero}
   38.94 +
   38.95 +Si decide que un fichero no pertenece a su repositorio, use la orden
   38.96 +\hgcmd{remove}; se borrará el fichero y le indicará a Mercurial que
   38.97 +deje de hacerle seguimiento.  Los ficheros eliminados se representan
   38.98 +con ``\texttt{R}'' al usar \hgcmd{status}.
   38.99 +\interaction{daily.files.remove}
  38.100 +
  38.101 +Después de hacer \hgcmd{remove} a un fichero, Mercurial dejará de
  38.102 +hacer seguimiento al mismo, incluso si recrea el fichero con el mismo
  38.103 +nombre en su directorio de trabajo. Si decide recrear un fichero con
  38.104 +el mismo nombre y desea que Mercurial le haga seguimiento, basta con
  38.105 +hacerle \hgcmd{add}. Mercurial sabrá que el fichero recientemente
  38.106 +adicionado no está relacionado con el fichero anterior que tenía el
  38.107 +mismo nombre.
  38.108 +
  38.109 +\subsection{Al eliminar un fichero no se afecta su historial}
  38.110 +
  38.111 +Es preciso tener en cuenta que eliminar un fichero tiene sólo dos
  38.112 +efectos.
  38.113 +\begin{itemize}
  38.114 +\item Se elimina la versión actual del fichero del directorio de 
  38.115 +trabajo.
  38.116 +\item Mercurial deja de hacer seguimiento a los cambios del fichero
  38.117 +  desde la próxima consignación.
  38.118 +\end{itemize}
  38.119 +Al eliminar un fichero \emph{no} se altera de ninguna manera el
  38.120 +\emph{historial} del mismo.
  38.121 +
  38.122 +Si actualiza su directorio de trabajo a un conjunto de cambios en el
  38.123 +cual el fichero que eliminó aún era tenido en cuenta, éste reaparecerá en
  38.124 +el directorio de trabajo, con los contenidos que este tenía cuando se
  38.125 +consignó tal conjunto de cambios.  Si usted actualiza el directorio de
  38.126 +trabajo a un conjunto de cambios posterior en el cual el fichero había
  38.127 +sido eliminado, Mercurial lo eliminará de nuevo del directorio de
  38.128 +trabajo.
  38.129 +
  38.130 +\subsection{Ficheros perdidos}
  38.131 +
  38.132 +Mercurial considera como \emph{perdido} un fichero que usted borró,
  38.133 +pero para el que no se usó \hgcmd{remove}.  Los ficheros perdidos se
  38.134 +representan con ``\texttt{!}'' al visualizar \hgcmd{status}.
  38.135 +Las órdenes de Mercurial generalmente no harán nada con los ficheros
  38.136 +perdidos.
  38.137 +\interaction{daily.files.missing}
  38.138 +
  38.139 +Si su repositorio contiene un fichero que \hgcmd{status} reporta como
  38.140 +perdido, y desea que el mismo se vaya, se puede usar 
  38.141 +\hgcmdargs{remove}{\hgopt{remove}{--after}} posteriormente para
  38.142 +indicarle a Mercurial que usted deseaba borrar tal fichero.
  38.143 +\interaction{daily.files.remove-after}
  38.144 +
  38.145 +Por otro lado, si borró un fichero perdido por accidente, puede usar
  38.146 +\hgcmdargs{revert}{\emph{nombre de fichero}} para recuperar el
  38.147 +fichero. Reaparecerá, sin modificaciones.
  38.148 +\interaction{daily.files.recover-missing}
  38.149 +
  38.150 +\subsection{Nota al margen: ¿Por qué decirle explícitamente a Mercurial
  38.151 +  que elimine un fichero?}
  38.152 +
  38.153 +Es posible que se haya preguntado por qué Mercurial exige que usted le
  38.154 +indique explícitamente que está borrando un fichero. Al principio del
  38.155 +desarrollo de Mercurial, este permitía que usted borrara el fichero
  38.156 +sin más; Mercurial se daría cuenta de la ausencia del fichero
  38.157 +automáticamente después de la ejecución de \hgcmd{commit}, y dejaría de
  38.158 +hacer seguimiento al fichero.  En la práctica, resultaba muy sencillo
  38.159 +borrar un fichero accidentalmente sin darse cuenta.
  38.160 +
  38.161 +\subsection{Atajo útil---agregar y eliminar ficheros en un solo paso}
  38.162 +
  38.163 +Mercurial ofrece una orden combinada, \hgcmd{addremove}, que agrega
  38.164 +los ficheros que no tienen seguimiento y marca los ficheros faltantes
  38.165 +como eliminados.
  38.166 +\interaction{daily.files.addremove}
  38.167 +La orden \hgcmd{commit} se puede usar con la opción \hgopt{commit}{-A} 
  38.168 +que aplica el mismo agregar-eliminar, seguido inmediatamente de una
  38.169 +consignación.
  38.170 +\interaction{daily.files.commit-addremove}
  38.171 +
  38.172 +\section{Copiar ficheros}
  38.173 +
  38.174 +Mercurial ofrece la orden \hgcmd{copy} para hacer una copia nueva de
  38.175 +un fichero.  Cuando se copia un fichero con esta orden, Mercurial
  38.176 +lleva un registro indicando que el nuevo fichero es una copia del
  38.177 +fichero original. Los ficheros copiados se tratan de forma especial  cuando
  38.178 +usted hace una fusión con el trabajo de alguien más.
  38.179 +
  38.180 +\subsection{Resultados de copiar un fichero durante una fusión}
  38.181 +
  38.182 +Durante una fusión los cambios ``siguen'' una copia.  Para ilustrar
  38.183 +lo que esto significa, haremos un ejemplo.  Comenzaremos con el mini
  38.184 +repositorio usual que contiene un solo fichero
  38.185 +\interaction{daily.copy.init}
  38.186 +Debemos hacer algo de trabajo en paralelo, de forma que tengamos algo para
  38.187 +fusionar. Aquí clonamos el repositorio.
  38.188 +\interaction{daily.copy.clone}
  38.189 +De vuelta en el repositorio inicial, usemos la orden \hgcmd{copy} para hacer
  38.190 +una copia del primer fichero que creamos.
  38.191 +\interaction{daily.copy.copy}
  38.192 +
  38.193 +Si vemos la salida de la orden \hgcmd{status}, el fichero copiado luce
  38.194 +tal como un fichero que se ha añadido normalmente.
  38.195 +\interaction{daily.copy.status}
  38.196 +Pero si usamos la opción \hgopt{status}{-C} de la orden
  38.197 +\hgcmd{status}, se imprimirá otra línea: el fichero \emph{desde} el
  38.198 +cual fue copiado nuestro fichero recién añadido.
  38.199 +\interaction{daily.copy.status-copy}
  38.200 +
  38.201 +Ahora, en el repositorio que clonamos, hagamos un cambio en
  38.202 +paralelo. Adicionaremos una línea de contenido al fichero original que
  38.203 +creamos.
  38.204 +\interaction{daily.copy.other}
  38.205 +Hemos modificado el fichero \filename{file} en este
  38.206 +repositorio. Cuando jalemos los cambios del primer repositorio y
  38.207 +fusionemos las dos cabezas, Mercurial propagará los cambios que hemos
  38.208 +hecho localmente en \filename{file} a su copia, \filename{new-file}.
  38.209 +\interaction{daily.copy.merge}
  38.210 +
  38.211 +\subsection{¿Por qué los cambios se reflejan en las copias?}
  38.212 +\label{sec:daily:why-copy}
  38.213 +
  38.214 +Este comportamiento de cambios en ficheros que se propagan a las
  38.215 +copias de los ficheros parecería esotérico, pero en la mayoría de
  38.216 +casos es absolutamente deseable.
  38.217 +Es indispensable recordar que esta propagación \emph{solamente} sucede
  38.218 +cuando fusionamos.  Por lo tanto si sobre un fichero se usa
  38.219 +\hgcmd{copy}, y se modifica el fichero original durante el curso
  38.220 +normal de su trabajo, nada pasará.
  38.221 +
  38.222 +Lo segundo a tener en cuenta es que las modificaciones solamente se
  38.223 +propagarán en las copias únicamente si los repositorios de los cuales
  38.224 +está jalando los cambios \emph{no saben} de la copia.
  38.225 +
  38.226 +Explicaremos a continuación la razón de este comportamiento de
  38.227 +Mercurial. Digamos que yo he aplicado un arreglo de un fallo importante a un
  38.228 +fichero fuente y consigné los cambios.  Por otro lado, usted decidió hacer
  38.229 +\hgcmd{copy} sobre el fichero en su repositorio, sin saber acerca del
  38.230 +fallo o sin ver el arreglo, y ha comenzado a trabajar sobre su copia
  38.231 +del fichero.
  38.232 +
  38.233 +Si jala y fusiona mis cambios y Mercurial \emph{no hubiera} propagado
  38.234 +los cambios en las copias, su fichero fuente tendría el fallo, a menos
  38.235 +que usted haya recordado propagar el arreglo del fallo a mano, el
  38.236 +mismo \emph{permanecería} en su copia del fichero.
  38.237 +
  38.238 +Mercurial previene esta clase de problemas, gracias a la propagación
  38.239 +automática del cambio que arregló el fallo del fichero original. Hasta
  38.240 +donde sé, Mercurial es el \emph{único} sistema de control de
  38.241 +revisiones que propaga los cambios en las copias de esta forma.
  38.242 +
  38.243 +Cuando su historial de cambios tiene un registro de la copia y la
  38.244 +subsecuente fusión, usualmente no es necesario propagar los cambios el
  38.245 +fichero original a las copias del mismo, y por esta razón Mercurial
  38.246 +propaga únicamente los cambios en las copias hasta este punto y no más
  38.247 +allá.
  38.248 +
  38.249 +
  38.250 +\subsection{Cómo hacer que los cambios \emph{no} sigan a la copia?}
  38.251 +
  38.252 +Si por algún motivo usted decide que esta característica de
  38.253 +propagación automática de cambios en las copias no es para usted,
  38.254 +simplemente use
  38.255 +la orden usual de su sistema para copiar ficheros (en sistemas tipo
  38.256 +Unix, es \command{cp}), y posteriormente use \hgcmd{add} sobre la nueva
  38.257 +copia hecha a mano.  Antes de hacerlo, de todas maneras, relea la
  38.258 +sección~\ref{sec:daily:why-copy}, y tome una decisión asegurándose que
  38.259 +este comportamiento no es el apropiado para su caso específico.
  38.260 +
  38.261 +\subsection{Comportamiento de la orden \hgcmd{copy}}
  38.262 +
  38.263 +Cuando usa la orden \hgcmd{copy}, Mercurial hace una copia de cada
  38.264 +fichero fuente tal como se encuentra en el directorio actual. Esto
  38.265 +significa que si usted hace
  38.266 +modificaciones a un fichero, y le aplica \hgcmd{copy} sin haber
  38.267 +consignado primero los cambios, la nueva copia contendrá también las
  38.268 +modificaciones que haya hecho hasta ese punto. (Este comportamiento me
  38.269 +parece poco intuitivo, y por tal motivo lo menciono.)
  38.270 +
  38.271 +La orden \hgcmd{copy} actúa de forma parecida a la orden \command{cp}
  38.272 +de Unix (puede usar el alias \hgcmd{cp} si le es más cómodo).  El
  38.273 +último argumento es el \emph{destino}, y todos los argumentos previos
  38.274 +son las \emph{fuentes}.  Si solamente indica un fichero como la
  38.275 +fuente, y el destino no existe, se crea un fichero nuevo con ese nombre.
  38.276 +\interaction{daily.copy.simple}
  38.277 +Si el destino es un directorio, Mercurial copia las fuentes en éste.
  38.278 +\interaction{daily.copy.dir-dest}
  38.279 +La copia de un directorio es recursiva, y preserva la estructura del
  38.280 +directorio fuente.
  38.281 +\interaction{daily.copy.dir-src}
  38.282 +Si tanto la fuente como el destino son directorios, la estructura de
  38.283 +la fuente se recrea en el directorio destino.
  38.284 +\interaction{daily.copy.dir-src-dest}
  38.285 +
  38.286 +De la misma forma que la orden \hgcmd{rename}, si copia un fichero
  38.287 +manualmente y desea que Mercurial sepa que ha copiado un fichero,
  38.288 +basta con aplicar la opción \hgopt{copy}{--after} a la orden 
  38.289 +\hgcmd{copy}.
  38.290 +\interaction{daily.copy.after}
  38.291 +
  38.292 +\section{Renombrar ficheros}
  38.293 +
  38.294 +La necesidad de renombrar un fichero es más común que hacer una copia
  38.295 +del mismo.  La razón por la cual discutí la orden \hgcmd{copy} antes
  38.296 +de hablar acerca de cambiar el nombre de los ficheros, es que
  38.297 +Mercurial trata el renombrar un fichero de la misma forma que una
  38.298 +copia.  Por lo tanto, saber lo que hace Mercurial cuando usted copia
  38.299 +un fichero le indica qué esperar cuando renombra un fichero.
  38.300 +
  38.301 +Cuando usa la orden \hgcmd{rename}, Mercurial hace una copia de cada
  38.302 +fichero fuente, lo borra y lo marca como fichero eliminado.
  38.303 +\interaction{daily.rename.rename}
  38.304 +La orden \hgcmd{status} muestra la nueva copia del fichero como
  38.305 +añadida y el fichero inicial de la copia, como eliminado.
  38.306 +\interaction{daily.rename.status}
  38.307 +De la misma forma en que se usa la orden \hgcmd{copy}, debemos usar la
  38.308 +opción \hgopt{status}{-C} de la orden \hgcmd{status} para verificar
  38.309 +que el fichero añadido realmente comienza a  ser seguido por Mercurial
  38.310 +como una copia del fichero original, ahora eliminado.
  38.311 +\interaction{daily.rename.status-copy}
  38.312 +
  38.313 +Igual que con \hgcmd{remove} y \hgcmd{copy}, puede indicársele a
  38.314 +Mercurial acerca de un renombramiento inmediato con la opción
  38.315 +\hgopt{rename}{--after}.   El comportamiento de la orden
  38.316 +\hgcmd{rename} y las opciones que acepta, son similares a la orden
  38.317 +\hgcmd{copy} en casi todo.
  38.318 +
  38.319 +\subsection{Renombrar ficheros y fusionar cambios}
  38.320 +
  38.321 +Dado que el renombrado de Mercurial se implementa como un
  38.322 +copiar-y-eliminar, la misma propagación de cambios ocurre cuando usted
  38.323 +fusiona después de renombrar como después de hacer una copia.
  38.324 +
  38.325 +Si yo modifico un fichero y usted lo renombra a un nuevo fichero, y
  38.326 +posteriormente fusionamos nuestros respectivos cambios, mi
  38.327 +modificación al fichero bajo su nombre original se propagará en el
  38.328 +fichero con el nuevo nombre. (Es lo que se esperaría que ``simplemente
  38.329 +funcione,''
  38.330 +pero, no todos los sistemas de control de revisiones hacen esto.)
  38.331 +
  38.332 +Aunque el hecho de que los cambios sigan la copia es una característica
  38.333 +respecto a la cual usted puede estar de acuerdo y decir ``si, puede
  38.334 +ser útil,'' debería ser claro
  38.335 +que el seguimiento de cambios de un renombramiento es definitivamente
  38.336 +importante.  Sin esto, sería muy sencillo que los cambios se
  38.337 +quedaran atrás cuando los ficheros se renombran.
  38.338 +
  38.339 +\subsection{Cambios de nombre divergentes y fusión}
  38.340 +
  38.341 +El caso de renombramiento con nombres divergentes ocurre cuando dos
  38.342 +desarrolladores comienzan  con un fichero---llamémoslo
  38.343 +\filename{foo}---en sus repositorios respectivos.
  38.344 +
  38.345 +\interaction{rename.divergent.clone}
  38.346 +%TODO we must either change the example's names, and these names, or
  38.347 +%use the original names. as of now, we keep the old names
  38.348 +Anne renombra el fichero a \filename{bar}.
  38.349 +\interaction{rename.divergent.rename.anne}
  38.350 +Mientras que Bob lo renombra como \filename{quux}.
  38.351 +\interaction{rename.divergent.rename.bob}
  38.352 +
  38.353 +Veo esto como un conflicto porque cada desarrollador ha expresado
  38.354 +intenciones diferentes acerca de cómo considera debería haberse
  38.355 +nombrado el fichero.
  38.356 +
  38.357 +¿Qué cree que debería pasar cuando fusionen su trabajo?
  38.358 +El comportamiento de Mercurial es que siempre preserva \emph{ambos}
  38.359 +nombres cuando fusiona  los conjuntos de cambios que contienen nombres
  38.360 +divergentes.
  38.361 +%TODO traducir texto interaccion
  38.362 +\interaction{rename.divergent.merge}
  38.363 +
  38.364 +Tenga en cuenta que Mercurial le advierte acerca de nombres
  38.365 +divergentes, pero deja que usted decida qué hacer con la divergencia
  38.366 +después de la fusión.
  38.367 +
  38.368 +\subsection{Cambios de nombre convergentes y fusión}
  38.369 +
  38.370 +Otra clase de conflicto al cambiar el nombre de ficheros ocurre cuando dos
  38.371 +personas eligen renombrar diferentes ficheros \emph{fuente} al mismo
  38.372 +\emph{destino}. En este caso Mercurial aplica su maquinaria de fusión
  38.373 +usual, y le permite a usted guiar la situación a una resolución adecuada.
  38.374 +
  38.375 +\subsection{Otros casos límite relacionados con renombramientos}
  38.376 +
  38.377 +Mercurial tiene un fallo de mucho tiempo en el cual no es capaz de
  38.378 +fusionar cuando por un lado hay un fichero con un nombre dado,
  38.379 +mientras que en otro hay un directorio con el mismo nombre. Esto está
  38.380 +documentado como~\bug{29}.
  38.381 +\interaction{issue29.go}
  38.382 +
  38.383 +\section{Recuperarse de equivocaciones}
  38.384 +
  38.385 +Mercurial tiene unas órdenes poderosas que le ayudarán a recuperarse
  38.386 +de equivocaciones comunes.
  38.387 +
  38.388 +La orden \hgcmd{revert} le permite deshacer cambios que haya hecho a
  38.389 +su directorio de trabajo. Por ejemplo, si aplicó \hgcmd{add} a un
  38.390 +fichero por accidente, ejecute \hgcmd{revert} con el nombre del
  38.391 +fichero que añadió, y en tanto que el fichero no haya sido tocado de
  38.392 +forma alguna, no será adicionado, ni seguido por Mercurial.  También
  38.393 +puede usar \hgcmd{revert} para deshacerse de cambios erróneos a un
  38.394 +fichero.
  38.395 +
  38.396 +Tenga en cuenta que la orden \hgcmd{revert} se usa para cambios que no
  38.397 +han sido consignados. Cuando haya consignado un cambio, si decide que
  38.398 +era un error, puede hacer algo todavía, pero sus opciones pueden estar
  38.399 +más limitadas.
  38.400 +
  38.401 +Para obtener información acerca de la orden \hgcmd{revert} y detalles
  38.402 +de cómo tratar con cambios consignados, vea el capítulo~\ref{chap:undo}.
  38.403 +
  38.404 +%%% Local Variables: 
  38.405 +%%% mode: latex
  38.406 +%%% TeX-master: "00book"
  38.407 +%%% End: