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