[RFC] BzrTagging updates

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:
> So one repository can encompass several unrelated projects which might
> use the same tag names (e.g. if they call it 'release-1'), 

I agree that this is useful.  Otherwise, you have a global namespace,
and it's hard to ensure that tags are unique within it.
(aaron.bentley at utoronto.ca--bzr/bzr--dev--0.8 anyone?  Didn't think so.)

> or it could
> have several related branches which disagree about the placement of a
> tag (e.g. if I move an existing tag but it hasn't propagated yet.)

I don't think that this is desirable.  When I have used systems (like
Fai) that allowed aliases to vary on a per-tree basis or on a global
basis, I have found I was always uncertain as to which aliases had which
definition in which tree, and so I always used the global aliases instead.

> They may or may not be in the same repository; it shouldn't matter
> because our model is that repositories are only about storage and are
> not semantic.

Thanks.  That really brings things into focus for me.  It's not that I
want aliases to be per-repository.  What I really want is for them to be
per-user.  Perhaps they can be associated with projects through the
first-commit id, or through the tree root, or maybe branches or
revisions should be associated with a project-uuid.

Using a project UUID that was an assignable value would mean that you
could prevent unwanted tag propogation by changing the UUID (e.g. when
one project splinters off from another).

This brings up thorny issues about propogation, too.

The system I've described may be complicated, but I think the goals make
sense:

1. People working on the same project should share a set of tags within
that project.
2. People working on different projects should not be aware of each
others' tags
3. Within a project, the values of tags should not be surprising, e.g.
they should not vary according to branch
4. Tags should propogate when people push, pull or merge.
5. Tag propogation should be smart; it should remember previous choices,
so that deleted tags don't reappear, and when one value is picked over
another, that choice is always respected.

To me, 1, 2, and 3 suggest a need for project UUIDs.  4 suggests that
push / pull / merge might require an additional tag-synchronization
phase.  5 suggests scalar history-aware merge, e.g. mark merge.  But
maybe there are other formulations that meet these goals.

I think I've said my piece now, in terms of what I think would be
desirable in a tag system.  Sorry to keep going on about it, and of
course, whatever system we go with, I'll do my best to make it work.

> To start with I would suggest we just simply write out a .bzrtags
> in human-readable form containing herringbone conflict markers.

Makes sense.  If this file is only meant to exist when there are
conflicts, BZRTAGS might be an appropriate name.

> Although handling tag conflicts properly is important, they will
> probably be relatively rare and so we shouldn't block on working out
> exact how they'll work.  We have the option in future to e.g. always
> prefer the local tag, or do some kind of smarter interactive resolution.

Agreed.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEmqOY0F+nu1YWqI0RAqg+AJ9DZbvKvsPZ9AwR+ug69oksl+KliACdFAhf
ElrQoy97solTSiROfQlb86o=
=0pwh
-----END PGP SIGNATURE-----