← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/es/guia-usuario/version_info.txt

  • Committer: John Arbash Meinel
  • Date: 2009-06-19 17:53:37 UTC
  • mto: This revision was merged to the branch mainline in revision 4466.
  • Revision ID: john@arbash-meinel.com-20090619175337-uozt3bntdd48lh4z
Update time_graph to use X:1 ratios rather than 0.xxx ratios.
It is just easier to track now that the new code is much faster.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/es/guia-usuario/version_info.txt
5
5
Repaso General
6
6
==============
7
7
 
8
 
Este documento describe las formas de usar ``bzr version-info`` como
 
8
Este documento describe las formas de usar ``bzr version-info`` como 
9
9
parte del proceso de embeber la informacion de vesion a un proyecto.
10
10
 
11
11
 
14
14
 
15
15
TODO: Figure out how to attach into ``setup.py``
16
16
 
17
 
Si usa un archivo Makefile para construir su proyecto, puede generar un
 
17
Si usa un archivo Makefile para construir su proyecto, puede generar un 
18
18
archivo on la informacion de version tan simple como::
19
19
 
20
20
  library/_version.py:
25
25
  * `version_info`: Un diccionario conteniendo informacion basica sobre el
26
26
    estado actual
27
27
 
28
 
  * `revisions`: Un diccionario listando todas las revisiones en
29
 
    el historial del tree, junto con los tiempos y los mensajes de
30
 
    los commits. Esto por defecto esta en blanco salvi que use ``--all``
31
 
    o `--include-history`` es provisto. Esto es util si quiere seguir
32
 
    que bugs arregla el lanzamiento de esa version. Para muchos proyectos
 
28
  * `revisions`: Un diccionario listando todas las revisiones en 
 
29
    el historial del tree, junto con los tiempos y los mensajes de 
 
30
    los commits. Esto por defecto esta en blanco salvi que use ``--all`` 
 
31
    o `--include-history`` es provisto. Esto es util si quiere seguir 
 
32
    que bugs arregla el lanzamiento de esa version. Para muchos proyectos 
33
33
    es mas informacion de la que se va a necesitar.
34
34
 
35
35
  * `file_revisions`: Un diccionario listando la revision que modifico
36
 
    por ultima vez todos los archivos del proyecto. Esto puede ser usado
37
 
    similarmente a como se usan las palabras claves ``$Id$`` en los
38
 
    archivos controlados en CVS. La ultima fecha de modificacion puede
39
 
    ser determinada mirando en el mapa de ``revisions``. Esto tambien
 
36
    por ultima vez todos los archivos del proyecto. Esto puede ser usado 
 
37
    similarmente a como se usan las palabras claves ``$Id$`` en los 
 
38
    archivos controlados en CVS. La ultima fecha de modificacion puede 
 
39
    ser determinada mirando en el mapa de ``revisions``. Esto tambien 
40
40
    esta vacio por defecto, y habilitado solo por ``--all`` o
41
41
    ``--include-file-revisions``.
42
 
 
 
42
    
43
43
 
44
44
Check Clean
45
45
===========
46
46
 
47
 
La mayoria de la informacion sobre el contenido del proyecto puede
 
47
La mayoria de la informacion sobre el contenido del proyecto puede 
48
48
ser determinada a muy bajo costo con solo leer las entradas de revisiones.
49
 
Sin embargo, puede ser util si el working tree fue actualizado completamente
50
 
cuando fue empaquetado, o si hubo alguna modificacion local. Al proveer
51
 
``--all`` o ``--check-clean``, ``bzr`` va a inspeccionar el working tree,
52
 
y definir el ``clean`` flag en ``version_info``, al igual que definir
 
49
Sin embargo, puede ser util si el working tree fue actualizado completamente 
 
50
cuando fue empaquetado, o si hubo alguna modificacion local. Al proveer 
 
51
``--all`` o ``--check-clean``, ``bzr`` va a inspeccionar el working tree, 
 
52
y definir el ``clean`` flag en ``version_info``, al igual que definir 
53
53
entradas en ``file_revisions`` como ``modified`` donde es apropiado.