# HG changeset patch
# User Igor TAmara <igor@tamarapatino.org>
# Date 1224269934 18000
# Node ID 8bedea2b8d60df36e6994c03f804760b5293bc7e
# Parent  e327e8e6811fa1f4f66bf32c2e88dbecbda7bd31
continuing translating branches

diff -r e327e8e6811f -r 8bedea2b8d60 es/Leame.1st
--- a/es/Leame.1st	Fri Oct 17 07:13:16 2008 -0500
+++ b/es/Leame.1st	Fri Oct 17 13:58:54 2008 -0500
@@ -31,6 +31,11 @@
  Milestone: Etapa
  Release: Versión o liberación de versión
 
+= Para compilar =
+Todavía no hemos logrado, pero he aquí algunas dependencias :
+
+apt-get install texlive-latex-extra tex4ht
+
 = Traductores =
 Por favor mantenga esta lista en orden alfabético
  * Igor Támara <igor@tamarapatino.org>
diff -r e327e8e6811f -r 8bedea2b8d60 es/branch.tex
--- a/es/branch.tex	Fri Oct 17 07:13:16 2008 -0500
+++ b/es/branch.tex	Fri Oct 17 13:58:54 2008 -0500
@@ -71,20 +71,22 @@
 correspondiente, y lo usará.
 \interaction{tag.log.v1.0}
 
-There's no limit on the number of tags you can have in a repository,
-or on the number of tags that a single revision can have.  As a
-practical matter, it's not a great idea to have ``too many'' (a number
-which will vary from project to project), simply because tags are
-supposed to help you to find revisions.  If you have lots of tags, the
-ease of using them to identify revisions diminishes rapidly.
+No hay límites en la cantidad de tags por reposirorio, o la cantidad
+de tags que una misma revisión pueda tener. Siendo prácticos, no es
+muy buena idea tener ``demasiados'' (la cantidad variará de un
+proyecto a otro), debido a que la intención es ayudarle a encontrar
+revisiones. Si tiene demasiados tags, la facilidad para identificar
+revisiones disminuirá rápidamente.
 
-For example, if your project has milestones as frequent as every few
-days, it's perfectly reasonable to tag each one of those.  But if you
-have a continuous build system that makes sure every revision can be
-built cleanly, you'd be introducing a lot of noise if you were to tag
-every clean build.  Instead, you could tag failed builds (on the
-assumption that they're rare!), or simply not use tags to track
-buildability.
+Por ejemplo, si su proyecto tiene etapas(milestones) frecuentes en pocos
+días, es perfectamente razonable asignarle un tag a cada una de
+ellas. Pero si tiene un sistema de construcción automática de binarios
+que asegura que cada revisión puede generarse limpiamente, estaría
+introduciendo mucho ruido si se usara un tag para cada generación
+exitosa. Más bien, podría usar tags para generaciones fallidas (en
+caso de que estas sean raras!), o simplemente evitar los tags para
+llevar cuenta de la posibilidad de generación de binarios.
+
 
 If you want to remove a tag that you no longer want, use
 \hgcmdargs{tag}{--remove}.