|
6
by mbp at sourcefrog
import all docs from arch |
1 |
******* |
2 |
Tagging |
|
3 |
******* |
|
4 |
||
5 |
||
6 |
It is useful to be able to point to particular revisions on a branch |
|
7 |
by symbolic names, rather than revision numbers or hashes. |
|
8 |
||
9 |
||
10 |
Proposal: just use branches |
|
11 |
--------------------------- |
|
12 |
||
13 |
This is probably the simplest model. |
|
14 |
||
15 |
In both Subversion and Arch, tags are basically just branches that do |
|
16 |
not differ from their parent revision. This has a few advantages: |
|
17 |
||
18 |
* We do not need to introduce another type of entity, which can |
|
19 |
simplify both understanding and implementation. We also do not need |
|
20 |
a special |
|
21 |
||
22 |
* If branches are cheap (through shared storage, etc) then tags are |
|
23 |
also appropriately cheap. |
|
24 |
||
25 |
* The general idea is familiar to people from those two systems (and |
|
26 |
probably some others). |
|
27 |
||
28 |
* People often do put tags in the wrong place, and need to update |
|
29 |
them, or want tags that move along from one state to another |
|
30 |
(e.g. ``STABLE``.) Tags-as-branches capture this through the usual |
|
31 |
versioning mechanism, rather than needing to invent a parallel |
|
32 |
versioning system for tags. |
|
33 |
||
34 |
There are some problems: |
|
35 |
||
36 |
* Users want tags to stay fixed, but branches are things that can be |
|
37 |
committed-to. So at one level there is a mismatch. |
|
38 |
||
39 |
* In particular, it can be easy to accidentally commit onto a tag |
|
40 |
branch rather than a "branch branch", and that commit can easily be |
|
41 |
'lost' and never integrated back to the right place. |
|
42 |
||
43 |
One possible resolution is to have a voluntary write-protect bit on a |
|
44 |
branch, which prevents accidental updates. (Similar to the unix owner |
|
45 |
write bit.) When it is necessary to update the branch, that bit can |
|
46 |
be removed or bypassed. |
|
47 |
||
48 |
This is an alternative to the Arch ``--seal`` mechanism. |
|
49 |
||
50 |
||
51 |
||
52 |
Proposal: tags within a branch |
|
53 |
------------------------------ |
|
54 |
||
55 |
(This is probably "crack"; I don't think we'll do this.) |
|
56 |
||
57 |
You can place tags on a branch as shorthand for a particular |
|
58 |
revision:: |
|
59 |
||
60 |
bzr tag rel3.14.18 |
|
61 |
||
62 |
bzr branch foo-project--main@rel3.14.18 |
|
63 |
||
64 |
Tags are alphanumeric identifiers that do not begin with a digit. |
|
65 |
Tags will cover an entire revision, not particular files. |
|
66 |
||
67 |
Another term sometimes used is "labels"; I think we're close enough to |
|
68 |
CVS's "tags" that it's good to be consistent. However, it does |
|
69 |
possibly clash with Arch's ``tag`` command and ``id-tagging-method`` |
|
70 |
(sheesh). |
|
71 |
||
72 |
In Subversion a tag is just a branch you don't commit to. You *can* |
|
73 |
work this way in Bazaar if you want to. (And until tags are |
|
74 |
implemented, this will be the way to do it.) |
|
75 |
||
76 |
I'm not sure if tags should be versioned objects or not. Options: |
|
77 |
||
78 |
* Tags are added or changed by a commit; they mark previous revisions |
|
79 |
but are only visible when looking from a later commit. |
|
80 |
||
81 |
* Tags are not versioned; if you move them they're gone. |
|
82 |
||
83 |
* Tags exist within their own versioning space. |
|
84 |
||
85 |
It is useful to have mutable tags, in case they're incorrectly placed |
|
86 |
or need to be updated. At the same time we do not want to lose |
|
87 |
history. I think in this model it is not helpful to update tags |
|
88 |
within revisions. One approach would be to version tags within a |
|
89 |
separate namespace, so |
|
90 |
||
91 |
| STABLE.0 |
|
92 |
| STABLE.1 |
|
93 |
| STABLE.2 |
|
94 |
||
95 |
as just STABLE it finds the most recent tag. |
|
96 |
||
97 |
(Is this kludgy?) |
|
98 |