tags in bzr

[John A Meinel]

Erik Bågfors wrote:
> On 5/13/05, Martin Pool <mbp at sourcefrog.net> wrote:
>
>>>So.. what do you all think? If you want it the same way as I do, I
>>>might be willing to implement it even.  It's quite an important
>>>feature for us.
>>
>>I think we should do this, despite my earlier reservations.  What
>>you've listed here should be reasonably simple.
>
>
> Great! :)
>
>
>>There are just a few open issues:
>>
>>- What names are allowed for tags?  I am inclined to say that, like
>>  programming language identifiers, they can't start with a digit so
>>  that we can distinguish them from revision numbers and pass both to -r.
>
>
> Two choices.
> 1) Use separate commandline for them. Such as --tag.  Then they can
> have any name or
> 2) Can't start with a digit (or maybe, must contain a alphabetical
> character) so that we can distinguish them.
>

I think I would go for the former. CVS does the later, but they also
disallow a whole bunch of characters (I really miss having . in tag
names). It's nice not to have to distinguish when you are asking for a
revision, but I think mentally you have already distinguished when you
are making the request.

>
>>- Should tags propagate across merges?  I think yes; people may have
>>  to adopt some conventions to avoid getting too many conflicts, such
>>  as starting personal-use tags with their username.
>
>
> Yes,

So you are saying that if I mark my revision 240 with "myrev-1.2", and
then you merge that, you suddenly get "myrev-1.2" in your tree?

I would actually say that this is not desired. Because I think of a tag
as a "tree-state" not a changeset. I'm not saying, this specific patch
is named myrev-1.2, I'm saying all of the patches that lead to this tree
state in aggregate is myrev-1.2.

>
>
>>- Are tags themselves versioned, and if so how?  The simplest thing is
>>  to say, no, they're not versioned.  Perhaps placing a tag should
>>  create a new revision, but that has the strange side-effect that if
>>  you check out a tag, you can no longer see the tag because it
>>  doesn't exist yet.
>
>
> Well... I would like to be able to place a tag on a old revision.  So
> I don't think they should create a new revision. Rather they should be
> an alias for a revision.

I agree, they should be a pointer to a revision, not a revision themselves.

>
> The way I see it used (among other ways) are:
> - ohh... I fixed that in revision 254 let me tag that
> $ bzr tag -r 254 'bug#123'
>
> - Great, then I'll pull that to my branch
> $ bzr merge --tag 'bug#123' http://....... (or pull..???)

The question is this a fully generic merge, where an ancestor is found,
and all the patches inbetween are merged, or does this just merge that
specific patch?

What is the specific syntax for cherry picking, do you just have to
supply the before version? Such as:
$ bzr merge ../other at 22:23

Would give you only the changes represented by changeset 23?

>
> But then the next questions are
> * Should a tag be globaly unique?
Globally, as in nobody else uses that tag? I think not. Unless you want
to use the same trick as revision numbers, where there is a secret UUID
associated with them, and the tag name is just a shortcut in that tree
for that UUID.
But since I don't really think merging should copy the tag, I don't
think unique is necessary.

> * Should you be able to move tags (I guess they need to be versioned then)

To me, they are simply aliases (pointers) to a specific revision of the
tree.

Actually, what about treating them the same as uuid and hash so you
would have:
bzr merge ../other-tree at tag:myrev-1.2

The simple implementation of tags to me, would be to have a directory
.bzr/tags/

With each tagname inside, and then you would have an append-only listing
of where the tag points right now. This means tag names are limited by
filesystem constraints (no /, on win32 no :,/,",...)

Contents of .bzr/tags/myrev-1.2:
# This is a .bzr tag listing, do not edit
revision revno: 442 uuid: ounotho-oteuh-uoehu-oeunt-oeuoenthunthoeu
	date: 2004-05-10 ...
revision revno: 445 uuid: ... date: 2005-02-19

Since you can only tag an entire tree state, the format of the file can
be very simple. You could make it as simple as only having a revision
number (though because it is an internal file, you probably want
something more concrete, like the uuid).
I thought you could also add the date when the tag was set.

Because it is append-only, it doesn't have to be versioned the same way
the working tree is.

Does bzr have any meta-information which is revisioned? As near as I can
tell, everything in .bzr is either the actual history, or meta
information which is regenerated all the time.

>
> Cheers,
> Erik
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050513/d8bf1d99/attachment.pgp