/brz/remove-bazaar

To get this branch, use:
bzr branch http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

« back to all changes in this revision

Viewing changes to doc/es/user-guide/version_info.txt

  • Committer: Vincent Ladeuil
  • Date: 2012-01-18 14:09:19 UTC
  • mto: This revision was merged to the branch mainline in revision 6468.
  • Revision ID: v.ladeuil+lp@free.fr-20120118140919-rlvdrhpc0nq1lbwi
Change set/remove to require a lock for the branch config files.

This means that tests (or any plugin for that matter) do not requires an
explicit lock on the branch anymore to change a single option. This also
means the optimisation becomes "opt-in" and as such won't be as
spectacular as it may be and/or harder to get right (nothing fails
anymore).

This reduces the diff by ~300 lines.

Code/tests that were updating more than one config option is still taking
a lock to at least avoid some IOs and demonstrate the benefits through
the decreased number of hpss calls.

The duplication between BranchStack and BranchOnlyStack will be removed
once the same sharing is in place for local config files, at which point
the Stack class itself may be able to host the changes.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/es/user-guide/version_info.txt
 
1
===========================
 
2
Usando ``bzr version-info``
 
3
===========================
 
4
 
 
5
Repaso General
 
6
==============
 
7
 
 
8
Este documento describe las formas de usar ``bzr version-info`` como
 
9
parte del proceso de embeber la informacion de vesion a un proyecto.
 
10
 
 
11
 
 
12
Projecto Python
 
13
===============
 
14
 
 
15
TODO: Figure out how to attach into ``setup.py``
 
16
 
 
17
Si usa un archivo Makefile para construir su proyecto, puede generar un
 
18
archivo on la informacion de version tan simple como::
 
19
 
 
20
  library/_version.py:
 
21
        bzr version-info --format=python > library/_version.py
 
22
 
 
23
Eso genera un archivo que contiene 3 diccionarios:
 
24
 
 
25
  * `version_info`: Un diccionario conteniendo informacion basica sobre el
 
26
    estado actual
 
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
 
33
    es mas informacion de la que se va a necesitar.
 
34
 
 
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
 
40
    esta vacio por defecto, y habilitado solo por ``--all`` o
 
41
    ``--include-file-revisions``.
 
42
 
 
43
 
 
44
Check Clean
 
45
===========
 
46
 
 
47
La mayoria de la informacion sobre el contenido del proyecto puede
 
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
 
53
entradas en ``file_revisions`` como ``modified`` donde es apropiado.