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.
10
Proposal: just use branches
11
---------------------------
13
This is probably the simplest model.
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:
18
* We do not need to introduce another type of entity, which can
19
simplify both understanding and implementation. We also do not need
22
* If branches are cheap (through shared storage, etc) then tags are
23
also appropriately cheap.
25
* The general idea is familiar to people from those two systems (and
26
probably some others).
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.
34
There are some problems:
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.
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.
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.
48
This is an alternative to the Arch ``--seal`` mechanism.
52
Proposal: tags within a branch
53
------------------------------
55
You can place tags on a branch as shorthand for a particular
60
bzr branch foo-project--main@rel3.14.18
62
Tags are alphanumeric identifiers that do not begin with a digit.
63
Tags will cover an entire revision, not particular files.
65
Another term sometimes used is "labels"; I think we're close enough to
66
CVS's "tags" that it's good to be consistent. However, it does
67
possibly clash with Arch's ``tag`` command and ``id-tagging-method``
70
In Subversion a tag is just a branch you don't commit to. You *can*
71
work this way in Bazaar if you want to. (And until tags are
72
implemented, this will be the way to do it.)
74
I'm not sure if tags should be versioned objects or not. Options:
76
* Tags are added or changed by a commit; they mark previous revisions
77
but are only visible when looking from a later commit.
79
This has the fairly strange effect that if you check out a previous
80
tag, you can't see the tag anymore (or you see the value it
83
* Tags are not versioned; if you move them they're gone.
85
* Tags exist within their own versioning space.
87
It is useful to have mutable tags, in case they're incorrectly placed
88
or need to be updated. At the same time we do not want to lose
89
history. I think in this model it is not helpful to update tags
90
within revisions. One approach would be to version tags within a
91
separate namespace, so
97
as just STABLE it finds the most recent tag.
99
Should tags propagate across merges, and if so how?
106
Add tags as non-versioned objects, that for the moment do not
107
propagate across branches.
added
removed
doc/tagging.txt
