changeset 498:2a1067c24be1

Merging javier changes

--- a/es/Leame.1st	Thu Nov 06 23:01:34 2008 -0500
+++ b/es/Leame.1st	Thu Nov 06 23:07:42 2008 -0500
@@ -99,7 +99,7 @@
 || preface.tex     || Javier Rojas  ||    100%    || 18/10/2008 ||  19/10/2008 ||
 || daily.tex       || Igor Támara   ||    100%    || 19/10/2008 ||  26/10/2008 ||
 || tour-basic.tex  || Javier Rojas  ||    100%    || 19/10/2008 ||  27/10/2008 ||
-|| undo.tex        || Igor Támara   ||     60%    || 26/10/2008 ||             ||
+|| undo.tex        || Igor Támara   ||     71%    || 26/10/2008 ||             ||
 || tour-merge.tex  || Javier Rojas  ||    100%    || 28/10/2008 ||  03/11/2008 ||
 || concepts.tex    || Javier Rojas  ||      7%    || 03/11/2008 ||             ||
 
@@ -132,6 +132,7 @@
 
  Anne: Ana
  Back out: Retroceder
+ Binary test: Prueba binaria
  Bob : Roberto
  Branch: Rama
  Bug: Fallo
@@ -150,6 +151,7 @@
  Mistake: Equivocación, cometida por un humano
  Patch: Parche
  Path: Ruta de archivo
+ Probe: Sondeo
  Pull: Jalar
  Push: Publicar
  Release: Versión o liberación de versión

--- a/es/undo.tex	Thu Nov 06 23:01:34 2008 -0500
+++ b/es/undo.tex	Thu Nov 06 23:07:42 2008 -0500
@@ -476,205 +476,214 @@
 \texttt{examples} directory works, but doesn't handle merge
 changesets.  Kind of an important omission.
 
-\subsection{Protect yourself from ``escaped'' changes}
+\subsection{Cómo protegerse de cambios que han ``escapado''}
 
-If you've committed some changes to your local repository and they've
-been pushed or pulled somewhere else, this isn't necessarily a
-disaster.  You can protect yourself ahead of time against some classes
-of bad changeset.  This is particularly easy if your team usually
-pulls changes from a central repository.
+Si ha consignado cambios a su repositorio local y estos han sido
+publicados o jalados en cualquier otro sitio, no es necesariamente un
+desastre. Puede protegerse de antemano de ciertas clases de conjuntos
+de cambios malos. Esto es particularmente sencillo si su equipo de
+trabajo jala cambios de un repositorio central.
 
-By configuring some hooks on that repository to validate incoming
-changesets (see chapter~\ref{chap:hook}), you can automatically
-prevent some kinds of bad changeset from being pushed to the central
-repository at all.  With such a configuration in place, some kinds of
-bad changeset will naturally tend to ``die out'' because they can't
-propagate into the central repository.  Better yet, this happens
-without any need for explicit intervention.
+Al configura algunos ganchos en el repositorio central para validar
+conjuntos de cambios(ver capítulo~\ref{chap:hook}), puede prevenir la
+publicación automáticamente de cierta clase de cambios malos.  Con tal
+configuración, cierta clase de conjuntos de cambios malos tenderán
+naturalmente a``morir'' debido a que no pueden propagarse al
+repositorio central.  Esto sucederá sin necesidad de intervención
+explícita.
 
-For instance, an incoming change hook that verifies that a changeset
-will actually compile can prevent people from inadvertantly ``breaking
-the build''.
+Por ejemplo, un gancho de cambios de entrada que verifique que un
+conjunto de cambios compila, puede prevenir que la gente ``rompa 
+la compilación'' inadvertidamente.
 
-\section{Finding the source of a bug}
+\section{Al encuentro de la fuente de un fallo}
 \label{sec:undo:bisect}
 
-While it's all very well to be able to back out a changeset that
-introduced a bug, this requires that you know which changeset to back
-out.  Mercurial provides an invaluable command, called
-\hgcmd{bisect}, that helps you to automate this process and accomplish
-it very efficiently.
+Aunque es muy bueno poder retroceder el conjunto de cambios que
+originó un fallo, se requiere que usted sepa cual conjunto de cambios
+retroceder.  Mercurial brinda una orden invaluable, llamada
+\hgcmd{bisect}, que ayuda a automatizar este proceso y a alcanzarlo
+muy eficientemente.
 
-The idea behind the \hgcmd{bisect} command is that a changeset has
-introduced some change of behaviour that you can identify with a
-simple binary test.  You don't know which piece of code introduced the
-change, but you know how to test for the presence of the bug.  The
-\hgcmd{bisect} command uses your test to direct its search for the
-changeset that introduced the code that caused the bug.
+La idea tras la orden \hgcmd{bisect} es que el conjunto de cambios que
+ha introducido un cambio de comportamiento pueda identificarse con una
+prueba binaria sencilla. No tiene que saber qué pieza de código
+introdujo el cambio, pero si requiere que sepa cómo probar la
+existencia de un fallo. La orden \hgcmd{bisect} usa su prueba para
+dirigir su búsqueda del conjunto de cambios que introdujo el código
+causante del fallo.
 
-Here are a few scenarios to help you understand how you might apply
-this command.
+A continuación un conjunto de escenarios que puede ayudarle a entender
+cómo puede aplicar esta orden.
 \begin{itemize}
-\item The most recent version of your software has a bug that you
-  remember wasn't present a few weeks ago, but you don't know when it
-  was introduced.  Here, your binary test checks for the presence of
-  that bug.
-\item You fixed a bug in a rush, and now it's time to close the entry
-  in your team's bug database.  The bug database requires a changeset
-  ID when you close an entry, but you don't remember which changeset
-  you fixed the bug in.  Once again, your binary test checks for the
-  presence of the bug.
-\item Your software works correctly, but runs~15\% slower than the
-  last time you measured it.  You want to know which changeset
-  introduced the performance regression.  In this case, your binary
-  test measures the performance of your software, to see whether it's
-  ``fast'' or ``slow''.
-\item The sizes of the components of your project that you ship
-  exploded recently, and you suspect that something changed in the way
-  you build your project.
+\item La versión más reciente de su programa tiene un fallo que usted
+  recuerda no estaba hace unas semanas, pero no sabe cuándo fue
+  introducido. En este caso, su prueba binaria busca la presencia de
+  tal fallo.
+\item Usted arregló un fallo en un apurto, y es hora de dar por
+  cerrado el caso en la base de datos de fallos de su equipo de
+  trabajo.   La base de datos de fallos requiere el ID del conjunto de
+  cambios que permita dar por cerrado el caso, pero usted no recuerda
+  qué conjunto de cambios arregló tal fallo.  De nuevo la prueba
+  binaria revisa la presencia del fallo.
+\item Su programa funciona correctamente, pero  core ~15\% más lento
+  que la última vez que lo midió. Usted desea saber qué conjunto de
+  cambios introdujo esta disminución de desempeño.  En este caso su
+  prueba binaria mide el desempeño de su programa, para ver dónde es
+  ``rápido'' y dónde es ``lento''.
+\item Los tamaños de los componentes del proyecto que usted lleva se
+  expandieron recientemente, y sospecha que algo cambio en la forma en
+  que se construye su proyecto.
 \end{itemize}
 
-From these examples, it should be clear that the \hgcmd{bisect}
-command is not useful only for finding the sources of bugs.  You can
-use it to find any ``emergent property'' of a repository (anything
-that you can't find from a simple text search of the files in the
-tree) for which you can write a binary test.
+Para estos ejemplos debería ser claro que la orden \hgcmd{bisect}
+es útil no solamente para encontrar la fuente de los fallos. Puede
+usarla para encontrar cualquier ``propiedad emergente'' de un
+repositorio(Cualquier cosa que usted no pueda encontrar con una
+búsqueda de texto sencilla sobre los archivos en el árbol) para la
+cual pueda escribir una prueba binaria.
 
-We'll introduce a little bit of terminology here, just to make it
-clear which parts of the search process are your responsibility, and
-which are Mercurial's.  A \emph{test} is something that \emph{you} run
-when \hgcmd{bisect} chooses a changeset.  A \emph{probe} is what
-\hgcmd{bisect} runs to tell whether a revision is good.  Finally,
-we'll use the word ``bisect'', as both a noun and a verb, to stand in
-for the phrase ``search using the \hgcmd{bisect} command.
+A continuación introduciremos algo terminología, para aclarar qué
+partes del proceso de búsqueda son su responsabilidad y cuáles de
+Mercurial.  Una \emph{prueba} es algo que \emph{usted} ejecuta cuando
+\hgcmd{bisect} elige un conjunto de cambios.  Un \emph{sondeo} es lo que
+\hgcmd{bisect} ejecuta para decidir si una revisión es buena.  Finalmente,
+usaremos la palabra ``biseccionar', en frases como ``buscar con la
+orden \hgcmd{bisect}''.
 
-One simple way to automate the searching process would be simply to
-probe every changeset.  However, this scales poorly.  If it took ten
-minutes to test a single changeset, and you had 10,000 changesets in
-your repository, the exhaustive approach would take on average~35
-\emph{days} to find the changeset that introduced a bug.  Even if you
-knew that the bug was introduced by one of the last 500 changesets,
-and limited your search to those, you'd still be looking at over 40
-hours to find the changeset that introduced your bug.
+Una forma sencilla de automatizar el proceso de búsqueda sería probar
+cada conjunto de cambios.  Lo cual escala muy poco. Si le tomó diez
+minutos hacer pruebas sobre un conjunto de cambios y tiene 10.000
+conjuntos de cambios en su repositorio, esta aproximación exhaustiva
+tomaría en promedio~35 \emph{días} para encontrar el conjunto de
+cambios que introdujo el fallo. Incluso si supiera que el fallo se
+introdujo en un de los últimos 500 conjuntos de cambios y limitara la
+búsqueda a ellos, estaría tomabdi más de 40 horas para encontrar al
+conjunto de cambios culpable.
 
-What the \hgcmd{bisect} command does is use its knowledge of the
-``shape'' of your project's revision history to perform a search in
-time proportional to the \emph{logarithm} of the number of changesets
-to check (the kind of search it performs is called a dichotomic
-search).  With this approach, searching through 10,000 changesets will
-take less than three hours, even at ten minutes per test (the search
-will require about 14 tests).  Limit your search to the last hundred
-changesets, and it will take only about an hour (roughly seven tests).
+La orden \hgcmd{bisect} usa su conocimiento de la ``forma'' de la
+historia de revisiones de su proyecto para hacer una búsqueda
+proporcional al \emph{logaritmo} del número de conjunto de cambios a
+revisar( el tipo de búsqueda que realiza se llama búsqueda
+binaria). Con esta aproximación, el buscar entre 10.000 conjuntos de
+cambios tomará menos de 3 horas, incluso a diez minutos por prueba(La
+búsqueda requerirá cerca de 14 pruebas). Al limitar la búsqueda a la
+última centena de conjuntos de cambios, tomará a lo sumo una
+hora(Apenas unas 7 pruebas).
 
-The \hgcmd{bisect} command is aware of the ``branchy'' nature of a
-Mercurial project's revision history, so it has no problems dealing
-with branches, merges, or multiple heads in a repoository.  It can
-prune entire branches of history with a single probe, which is how it
-operates so efficiently.
+La orden \hgcmd{bisect} tiene en cuenta la naturaleza ``ramificada''
+de la historia de revisiones del proyecto con Mercurial, así que no
+hay problemas al tratar con ramas, fusiones o cabezas múltiples en un
+repositorio.  Puede evitar ramas enteras de historia con un solo
+sondeo.
 
-\subsection{Using the \hgcmd{bisect} command}
+\subsection{Uso de la orden \hgcmd{bisect}}
 
-Here's an example of \hgcmd{bisect} in action.
+A continuación un ejemplo de \hgcmd{bisect} en acción.
 
 \begin{note}
-  In versions 0.9.5 and earlier of Mercurial, \hgcmd{bisect} was not a
-  core command: it was distributed with Mercurial as an extension.
-  This section describes the built-in command, not the old extension.
+  En las versiones 0.9.5 y anteriores de Mercurial, \hgcmd{bisect} no
+  era una orden incluída en la distribución principal: se ofrecía como
+  una extensión de Mercurial. Esta sección describe la orden embebida
+  y no la extensión anterior.
 \end{note}
 
-Now let's create a repository, so that we can try out the
-\hgcmd{bisect} command in isolation.
+Creamos un repostorio para probar el comando \hgcmd{bisect} de forma
+aislada
 \interaction{bisect.init}
-We'll simulate a project that has a bug in it in a simple-minded way:
-create trivial changes in a loop, and nominate one specific change
-that will have the ``bug''.  This loop creates 35 changesets, each
-adding a single file to the repository.  We'll represent our ``bug''
-with a file that contains the text ``i have a gub''.
+Simularemos de forma sencilla un proyecto con un fallo: haremos
+cambios triviales en un ciclo, e indicaremos que un cambio específico
+sea el ``fallo''.  Este ciclo crea 35 conjuntos de cambios, cada uno
+añade un único archivo al repositorio. Representaremos nuestro ``fallo''
+con un fichero que contiene el texto ``tengo un gub''.
 \interaction{bisect.commits}
 
-The next thing that we'd like to do is figure out how to use the
-\hgcmd{bisect} command.  We can use Mercurial's normal built-in help
-mechanism for this.
+A continuación observaremos cómo usar la orden \hgcmd{bisect}. Podemos
+usar el mecanismo de ayuda embebida que trae Mercurial.
 \interaction{bisect.help}
 
-The \hgcmd{bisect} command works in steps.  Each step proceeds as follows.
+La orden \hgcmd{bisect} trabaja en etapas, de la siguiente forma:
 \begin{enumerate}
-\item You run your binary test.
+\item Usted ejecuta una prueba binaria.
   \begin{itemize}
-  \item If the test succeeded, you tell \hgcmd{bisect} by running the
-    \hgcmdargs{bisect}{good} command.
-  \item If it failed, run the \hgcmdargs{bisect}{--bad} command.
+  \item Si la prueba es exitosa, usted se lo indicará a \hgcmd{bisect}
+    ejecutando la orden \hgcmdargs{bisect}{good}.
+  \item Si falla, ejecutará la orden \hgcmdargs{bisect}{--bad}.
   \end{itemize}
-\item The command uses your information to decide which changeset to
-  test next.
-\item It updates the working directory to that changeset, and the
-  process begins again.
+\item La orden usa su información para decidir qué conjuntos de
+  cambios deben probarse a continuación.
+\item Actualiza el directorio de trabajo a tal conjunto de cambios y
+  el proceso se lleva a cabo de nuevo.
 \end{enumerate}
-The process ends when \hgcmd{bisect} identifies a unique changeset
-that marks the point where your test transitioned from ``succeeding''
-to ``failing''.
+El proceso termina cuando \hgcmd{bisect} identifica un único conjunto
+de cambios que marca el punto donde se encontró la transición de
+``exitoso'' a ``fallido''.
 
-To start the search, we must run the \hgcmdargs{bisect}{--reset} command.
+Para comenzar la búsqueda, es indispensable ejecutar la orden
+\hgcmdargs{bisect}{--reset}.
 \interaction{bisect.search.init}
 
-In our case, the binary test we use is simple: we check to see if any
-file in the repository contains the string ``i have a gub''.  If it
-does, this changeset contains the change that ``caused the bug''.  By
-convention, a changeset that has the property we're searching for is
-``bad'', while one that doesn't is ``good''.
+En nuestro caso, la prueba binaria es sencilla: revisamos si el
+archivo en el repositorio contiene la cadena ``tengo un gub''.  Si la
+tiene, este conjunto de cambios contiene aquel que ``causó el fallo''.
+Por convención, un conjunto de cambios que tiene la propiedad que
+estamos buscando es ``malo'', mientras que el otro que no la tiene es
+``bueno''.
 
-Most of the time, the revision to which the working directory is
-synced (usually the tip) already exhibits the problem introduced by
-the buggy change, so we'll mark it as ``bad''.
+En la mayoría de casos, la revisión del directorio actual (usualmente
+la punta) exhibe el problema introducido por el cambio con el fallo,
+por lo tanto la marcaremos como ``mala''.
 \interaction{bisect.search.bad-init}
 
-Our next task is to nominate a changeset that we know \emph{doesn't}
-have the bug; the \hgcmd{bisect} command will ``bracket'' its search
-between the first pair of good and bad changesets.  In our case, we
-know that revision~10 didn't have the bug.  (I'll have more words
-about choosing the first ``good'' changeset later.)
+Nuestra próxima tarea es nominar al conjunto de cambios que sabemos
+\emph{no} tiene el fallo; la orden \hgcmd{bisect} ``acotará'' su
+búsqueda entre el primer par de conjuntos de cambios buenos y malos.
+En nuestro caso, sabemos que la revisión~10 no tenía el fallo.  (Más
+adelante diré un poco más acerca de la elección del conjunto de
+cambios ``bueno''.)
 \interaction{bisect.search.good-init}
 
-Notice that this command printed some output.
+Note que esta orden mostró algo.
 \begin{itemize}
-\item It told us how many changesets it must consider before it can
-  identify the one that introduced the bug, and how many tests that
-  will require.
-\item It updated the working directory to the next changeset to test,
-  and told us which changeset it's testing.
+\item Nos dijo cuántos conjuntos de cambios debe considerar antes de
+  que pueda identifica aquel que introdujo el fallo, y cuántas pruebas
+  se requerirán.
+\item Actualizó el directorio de trabajo al siguiente conjunto de
+  cambios, y nos dijo qué conjunto de cambios está evaluando.
 \end{itemize}
 
-We now run our test in the working directory.  We use the
-\command{grep} command to see if our ``bad'' file is present in the
-working directory.  If it is, this revision is bad; if not, this
-revision is good.
+Ahora ejecutamos nuestra prueba en el directorio de trabajo. Usamos la
+orden \command{grep} para ver si nuestro fichero ``malo'' está
+presente en el directorio de trabajo.  Si lo está, esta revisión es
+mala; si no esta revisión es buena.
 \interaction{bisect.search.step1}
 
-This test looks like a perfect candidate for automation, so let's turn
-it into a shell function.
+Esta prueba luce como candidata perfecta para automatizarse, por lo
+tanto la convertimos en una función de interfaz de comandos.
 \interaction{bisect.search.mytest}
-We can now run an entire test step with a single command,
+Ahora podemos ejecutar un paso entero de pruebas con un solo comando,
 \texttt{mytest}.
 \interaction{bisect.search.step2}
-A few more invocations of our canned test step command, and we're
-done.
+Unas invocaciones más de nuestra prueba, y hemos terminado.
 \interaction{bisect.search.rest}
 
-Even though we had~40 changesets to search through, the \hgcmd{bisect}
-command let us find the changeset that introduced our ``bug'' with
-only five tests.  Because the number of tests that the \hgcmd{bisect}
-command performs grows logarithmically with the number of changesets to
-search, the advantage that it has over the ``brute force'' search
-approach increases with every changeset you add.
+Aunque teníamos unos~40 conjuntos de cambios en los cuales buscar, la
+orden \hgcmd{bisect} nos permitió encontrar el conjunto de cambios que
+introdujo el ``fallo'' con sólo cinco pruebas.  Porque el número de
+pruebas que la orden \hgcmd{bisect} ejecuta crece logarítmicamente con
+la cantidad de conjuntos de cambios a buscar, la ventaja que esto
+tiene frente a la  búsqueda por``fuerza bruta'' crece con cada
+conjunto de cambios que usted adicione.
 
-\subsection{Cleaning up after your search}
+\subsection{Limpieza después de la búsqueda}
 
-When you're finished using the \hgcmd{bisect} command in a
-repository, you can use the \hgcmdargs{bisect}{reset} command to drop
-the information it was using to drive your search.  The command
-doesn't use much space, so it doesn't matter if you forget to run this
-command.  However, \hgcmd{bisect} won't let you start a new search in
-that repository until you do a \hgcmdargs{bisect}{reset}.
+Cuando haya terminado de usar la orden \hgcmd{bisect} en un
+repositorio, puede usar la orden \hgcmdargs{bisect}{reset} para
+deshacerse de la información que se estaba usando para lograr la
+búsqueda. Lar orden no usa mucho espacio, así que no hay problema si
+olvida ejecutar la orden.  En todo caso, \hgcmd{bisect} no le
+permitirá comenzar una nueva búsqueda sobre el repositorio hasta que
+no aplique \hgcmdargs{bisect}{reset}.
 \interaction{bisect.search.reset}
 
 \section{Tips for finding bugs effectively}