hgbook
diff es/branch.tex @ 330:8bedea2b8d60
continuing translating branches
author | Igor TAmara <igor@tamarapatino.org> |
---|---|
date | Fri Oct 17 13:58:54 2008 -0500 (2008-10-17) |
parents | 1afa6cce993d |
children | 3502b859cfe4 |
line diff
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}.