1.1 --- a/es/Leame.1st	Fri Oct 17 07:13:16 2008 -0500
     1.2 +++ b/es/Leame.1st	Fri Oct 17 13:58:54 2008 -0500
     1.3 @@ -31,6 +31,11 @@
     1.4   Milestone: Etapa
     1.5   Release: Versión o liberación de versión
     1.6  
     1.7 += Para compilar =
     1.8 +Todavía no hemos logrado, pero he aquí algunas dependencias :
     1.9 +
    1.10 +apt-get install texlive-latex-extra tex4ht
    1.11 +
    1.12  = Traductores =
    1.13  Por favor mantenga esta lista en orden alfabético
    1.14   * Igor Támara <igor@tamarapatino.org>

     2.1 --- a/es/branch.tex	Fri Oct 17 07:13:16 2008 -0500
     2.2 +++ b/es/branch.tex	Fri Oct 17 13:58:54 2008 -0500
     2.3 @@ -71,20 +71,22 @@
     2.4  correspondiente, y lo usará.
     2.5  \interaction{tag.log.v1.0}
     2.6  
     2.7 -There's no limit on the number of tags you can have in a repository,
     2.8 -or on the number of tags that a single revision can have.  As a
     2.9 -practical matter, it's not a great idea to have ``too many'' (a number
    2.10 -which will vary from project to project), simply because tags are
    2.11 -supposed to help you to find revisions.  If you have lots of tags, the
    2.12 -ease of using them to identify revisions diminishes rapidly.
    2.13 -
    2.14 -For example, if your project has milestones as frequent as every few
    2.15 -days, it's perfectly reasonable to tag each one of those.  But if you
    2.16 -have a continuous build system that makes sure every revision can be
    2.17 -built cleanly, you'd be introducing a lot of noise if you were to tag
    2.18 -every clean build.  Instead, you could tag failed builds (on the
    2.19 -assumption that they're rare!), or simply not use tags to track
    2.20 -buildability.
    2.21 +No hay límites en la cantidad de tags por reposirorio, o la cantidad
    2.22 +de tags que una misma revisión pueda tener. Siendo prácticos, no es
    2.23 +muy buena idea tener ``demasiados'' (la cantidad variará de un
    2.24 +proyecto a otro), debido a que la intención es ayudarle a encontrar
    2.25 +revisiones. Si tiene demasiados tags, la facilidad para identificar
    2.26 +revisiones disminuirá rápidamente.
    2.27 +
    2.28 +Por ejemplo, si su proyecto tiene etapas(milestones) frecuentes en pocos
    2.29 +días, es perfectamente razonable asignarle un tag a cada una de
    2.30 +ellas. Pero si tiene un sistema de construcción automática de binarios
    2.31 +que asegura que cada revisión puede generarse limpiamente, estaría
    2.32 +introduciendo mucho ruido si se usara un tag para cada generación
    2.33 +exitosa. Más bien, podría usar tags para generaciones fallidas (en
    2.34 +caso de que estas sean raras!), o simplemente evitar los tags para
    2.35 +llevar cuenta de la posibilidad de generación de binarios.
    2.36 +
    2.37  
    2.38  If you want to remove a tag that you no longer want, use
    2.39  \hgcmdargs{tag}{--remove}.