1.1 --- a/es/branch.tex	Fri Oct 17 05:42:54 2008 -0500
     1.2 +++ b/es/branch.tex	Fri Oct 17 13:58:54 2008 -0500
     1.3 @@ -71,20 +71,22 @@
     1.4  correspondiente, y lo usará.
     1.5  \interaction{tag.log.v1.0}
     1.6  
     1.7 -There's no limit on the number of tags you can have in a repository,
     1.8 -or on the number of tags that a single revision can have.  As a
     1.9 -practical matter, it's not a great idea to have ``too many'' (a number
    1.10 -which will vary from project to project), simply because tags are
    1.11 -supposed to help you to find revisions.  If you have lots of tags, the
    1.12 -ease of using them to identify revisions diminishes rapidly.
    1.13 -
    1.14 -For example, if your project has milestones as frequent as every few
    1.15 -days, it's perfectly reasonable to tag each one of those.  But if you
    1.16 -have a continuous build system that makes sure every revision can be
    1.17 -built cleanly, you'd be introducing a lot of noise if you were to tag
    1.18 -every clean build.  Instead, you could tag failed builds (on the
    1.19 -assumption that they're rare!), or simply not use tags to track
    1.20 -buildability.
    1.21 +No hay límites en la cantidad de tags por reposirorio, o la cantidad
    1.22 +de tags que una misma revisión pueda tener. Siendo prácticos, no es
    1.23 +muy buena idea tener ``demasiados'' (la cantidad variará de un
    1.24 +proyecto a otro), debido a que la intención es ayudarle a encontrar
    1.25 +revisiones. Si tiene demasiados tags, la facilidad para identificar
    1.26 +revisiones disminuirá rápidamente.
    1.27 +
    1.28 +Por ejemplo, si su proyecto tiene etapas(milestones) frecuentes en pocos
    1.29 +días, es perfectamente razonable asignarle un tag a cada una de
    1.30 +ellas. Pero si tiene un sistema de construcción automática de binarios
    1.31 +que asegura que cada revisión puede generarse limpiamente, estaría
    1.32 +introduciendo mucho ruido si se usara un tag para cada generación
    1.33 +exitosa. Más bien, podría usar tags para generaciones fallidas (en
    1.34 +caso de que estas sean raras!), o simplemente evitar los tags para
    1.35 +llevar cuenta de la posibilidad de generación de binarios.
    1.36 +
    1.37  
    1.38  If you want to remove a tag that you no longer want, use
    1.39  \hgcmdargs{tag}{--remove}.