Mercurial > hgbook
changeset 429:8bedea2b8d60
continuing translating branches
| author | Igor TAmara <igor@tamarapatino.org> |
|---|---|
| date | Fri, 17 Oct 2008 13:58:54 -0500 |
| parents | e327e8e6811f |
| children | 3502b859cfe4 |
| files | es/Leame.1st es/branch.tex |
| diffstat | 2 files changed, 20 insertions(+), 13 deletions(-) [+] |
line wrap: on
line diff
--- 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>
--- 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}.