[RFC] BzrTagging updates

[Aaron Bentley]

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

Matthew D. Fuller wrote:
> On Fri, Jun 23, 2006 at 09:49:38AM -0400 I heard the voice of
> Aaron Bentley, and lo! it spake thus:

>> I am saying that when tags conflict, each tag conflict must be
>> resolved in favour of one or the other.  Not that one branch's tags
>> must all supersede the other branch's tags.
> 
> That's what I meant.

Yeah, I thought so, but wasn't certain.

>> With per-branch tags, either someone else will merge you and get tag
>> conflicts, or you'll merge yourself and get tag conflicts.  So
>> you're either a sadist or a masochist.
> 
> Or, you merge based on tag-id, and don't merge renames, which was the
> root of my concept.   :)

But you can't have two tags with the same name, even with tag ids.  So
you still have to rename tags.  To get sensible names, the user needs to
select it.  So by picking a name like JIM_REVIEWED, you're being a jerk
to people anyone who merges you.

> The renames exist to support having other branch's tags not interfere
> with your naming of your branch's tags.  The not propogating renames
> keeps that from creating a problem when you merge back the other way.

I don't think having tag ids really improves things.  You wind up in a
situation in which people have "the same" tags, but they're called
different things (imagine 4 people rename JIM_REVIEWED to different
things!).

> Again, I don't suggest that these sort of things will or SHOULD be
> common, and I agree they're hardly ever a good idea, but I'm
> uncomfortable with declaring that such a thing should NEVER be
> allowed.

I don't have a problem with outlawing behavior, in general.  It
shouldn't be done lightly, but too many degrees of freedom is frequently
just as bad as not enough freedom.  Where it makes the system simpler
for our users, we should not be afraid to make choices.

This kind of thing is the reason we don't support versioning POSIX
modes, aside from the execute bit.  We don't think that's very useful
for software development.  Though it might be useful for archiving /etc,
we're not making a tool for archiving.

And note that nothing's truly forbidden.  If a small group of people
need a different tagging system, they can implement it as a plugin.  If
it's not a small group, then we've probably made a mistake.

The cases you're discussing sound like personal-use tags; they don't
sound like things that the user wants to propogate.  So an alternative
to your solution is to have global and local tags, where local tags
don't propogate (by default).  Presumably, there'd be a way to refer to
a local tag in another branch, if e.g. I really wanted to look at the
JIM_REVIEWED revision in http://bazaar-ng.org/bzr/bzr.dev

I think that a global/local distinction might easier to grok than your
system, in which "the same" tag exists in two branches, but frequently
has different names and refers to different revisions.

But I do question whether tags are the right answer for that case at
all.  Branches are local, they have user assigned names, they refer to
particular revisions, they're part of the -r namespace, and they can
easily be updated.  Why wouldn't they work in that situation?

> In general, I do too.  But, I don't think that's the ONLY possible way
> people may want to use tags, and declaring that we never support tag
> names pointing in different places feels wrong to me.  It feels like
> the sort of choice that opens up a lot of opportunity for collateral
> damage down the road.

Well, I think people who work together need to be able to agree on
things.  And I think tags are one of the things they need to agree on,
because they're names for revisions, and these names are essential to
communication.  If you're trying to communicate using these names, and
you don't can't come to an agreement on what they mean, you've got a
dysfunctional environment, and tools can't help you with that.

> It's generally "bad" in much the same sense for two "related" branches
> to have two different files (by file-id) referred to by the same
> filename, but we don't (and shouldn't) outlaw that layout in the tool.

It's not that rare.  For example, bzrtools contains 'NEWS.Shelf', which
is renamed from 'NEWS' in the source Shelf plugin.  I don't see it as bad.

> Neither, I think, should we do so with the equivalent in tags.

But files are more than their names.  Many people would agree NEWS.Shelf
is the same file as NEWS in the shelf plugin.  They have exactly the
same contents, for example.

But I think it's much more likely for people to identify tags with their
names, because there's so little to them.  Tags themselves are a layer
of indirection, and I'd prefer to avoid sticking a second layer of
indirection beneath them.  I think that would make bzr harder to use.

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

iD8DBQFEng220F+nu1YWqI0RAsEcAJ9z0u4dxe2BQy8dNAKCzpWhIFa8jgCfYvUZ
mou3KX42L44etZEnK5EODMI=
=e6QD
-----END PGP SIGNATURE-----