[RFC] BzrTagging updates

[Matthew D. Fuller]

On Thu, Jun 22, 2006 at 10:05:12AM -0400 I heard the voice of
Aaron Bentley, and lo! it spake thus:
> 
> 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.

That helps me too; the only things I could figure you meant by
"per-repository" were all completely nutso  ;)


> 1. People working on the same project [...]
> 2. People working on different projects [...]
> 4. Tags should propogate when people push, pull or merge.
> 5. Tag propogation should be smart; [...]

Really, our only disagreement here is that you're creating a
'project', whereas I just want 'branch'.

It's here that it really becomes a schism:

> 3. Within a project, the values of tags should not be surprising,
>    e.g.  they should not vary according to branch

I think this is more a project management issue; that is, making this
decision in the tool feels too much like implementing policy instead
of tools.  Indeed, the idea of a 'project' here even goes far enough
that way to make me a little skittish.  Now I have to create this
'project' and define branches in/out of it to share/not share tags?
[I somewhat abandon 'project' below and deal with it more in terms of
branch relations, so that bit of this paragraph can probably safely be
ignored.]

I agree with the sentiment that down this road lies madness, and that
it's generally a bad idea to go down it very much.  And I think the
usages of it would be quite rare.  But, I think building a system that
can't handle it is the wrong answer.  You basically end up declaring
that when tags conflict, one branch MUST be made to be in sync with
the other.

I may, just to pick a strawman, want each branch of a given project to
have a LAST_KNOWN_GOOD tag, which would naturally be different on each
branch since they're going different directions.  When I branch from
one of them, I should inherit its L_K_G, but I'll move it later when I
get another known good state.  I may have 5 or 6 branches of some
program, each with their own L_K_G, each pointing at revisions that
don't exist in any of the other branches.  Or consider a JIM_REVIEWED
tag on each branch, keeping track of how far along it Jim has looked
at the changes.


Every scheme has its wart; mine is the renaming.  If I merge a branch
with a tag the same name as one I have, I probably want them both, but
obviously one of them has to be renamed internally at least.  But that
may yield an unuseful name, so we want the ability to user-rename.
But it doesn't seem we want to merge such things (and anyway
non-conflict case tag renaming seems nasty to me), so we don't want it
to be a general thing, just a conflict resolution thing, so...   eyah!

Icky.  I hate it.  But, it seems to be the simplest discontinuity
point of the schemes I've thought of.  Your discontinuity seems to be
"When two branches touch, all their tags must become equivalent",
which jars me a lot more.


> 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,

Oh, please do!  If we don't end up agreeing, the next best thing is to
define as precisely as possible the points of disagreement.  And I
think I at least am still a little fuzzy on them; I think I'm
representing your position right above, but I could be off in left
field.


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

I'm not sure an editable file is even the best thing here (though that
depends on some of the above issues, in terms of "what kind of
conflicts will we have?").  But, assuming that; I kinda like hiding it
off in .bzr/ somewhere, and just have a 'bzr tag-resolve' or the like
launch $EDITOR on it directly.  "OK, I've created this file in your
working dir, edit that then tell me to look at it again" feels kinda
grody.  That may not play so well with configs like GUI editors,
though.


> > 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.
> 
> Agreed.

Ditto, with the caveat above that it probably IS necessary to figure
out what sort of conflicts/resolutions the system will require/allow
to get the rest together; the details of how to deal with them can
certainly be put off a bit.


-- 
Matthew Fuller     (MF4839)   |  fullermd at over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.