[RFC] BzrTagging updates

[Aaron Bentley]

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

Matthew D. Fuller wrote:
> Really, our only disagreement here is that you're creating a
> 'project', whereas I just want 'branch'.

There are certainly development styles where everyone working on a
project is also working on the same branch.

But bzr is a tool intended to help people cooperate on software
development, with each running their own branch.  It's not controversial
 to call that a project.  It's not surprising that we might want a way
of identifying that thing.

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

The goal of a distributed VCS is to make it easier for people to
collaborate.  So I think bzr should at least  make it possible for it to
be easy for values of tags to not be surprising.

> Indeed, the idea of a 'project' here even goes far enough
> that way to make me a little skittish.  

But surely you'd agree that bzr.dev and bzr.w-changeset have something
in common that bzrtools and bzr.dev don't have in common?  Right now, we
have no way of denoting that.

> Now I have to create this
> 'project' and define branches in/out of it to share/not share tags?

No.  The project UUID would be one of the things that was created by bzr
init.  It would propogate to branches automatically.  You'd only want to
change it if you were creating a fork.

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

Are you talking about per-branch tags here?

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

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

This is like "doctor, it hurts every time I stab myself in the eye".  If
you know you're using a system in which tags from different branches
propogate, choosing LAST_KNOWN_GOOD just going to cause pain.

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.

For something like LAST_KNOWN_GOOD to work, you'd have to have
non-propogating tags.

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

Yeah, but also consider GOOD.branch1 and GOOD.branch2 and
JIM_REVIEWED.branch3.  Now you know you won't have conflicts down the line.

> 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

No, frequently, you'll want to choose one value over the other.  There
can be only one bzr-0.8, so if there are two tags, one is wrong and one
is right.

I found with CVS, it wasn't uncommon make a tag, and then fix it,
usually within a couple of hours.  But the only tags that were always
moving were the branch tags, and we don't need tags for that.  In fact,
couldn't LAST_GOOD be a branch rather than a tag?

>, but
> obviously one of them has to be renamed internally at least.

I think putting a layer of indirection on tag names is very icky.  I
don't think its benefits outweight its costs.

>  But that
> may yield an unuseful name, so we want the ability to user-rename.

Why not just get the user to pick useful names from the get-go, on the
assumption that all branches will merge eventually, and someone will
have to sort out the mess?

Other alternatives:
1. have some tags propogate and some tags not propogate
2. include additional distinguishing info.

Additional distinguising info might mean something like this:

~/bzr/ab$ bzr tag --branch LAST_KNOWN_GOOD

Instead of creating LAST_KNOWN_GOOD, the --branch means it creates

LAST_KNOWN_GOOD.bzr/ab.abentley at panoramicfeedback.com

Which can be referred to as LAST_KNOWN_GOOD if it's the only one, or
LAST_KNOWN_GOOD.bzr/ab if it's the only one, or by its full name if
necessary.

> 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 it's because of the differing usage.  I want tags that are
permanent, almost unmoving markers of states of development: "0.8",
"bzr.log-branch-point", "merge-encoding-branch".  If logs are intended
as reference points among developers, it's counterproductive for them to
differ among branches, because then it's "merge-encoding-branch from
http://bazaar-vcs.org/bzr/bzr.dev", and if we have to refer to branches,
we might as well use revnos.  And it's even worse if they're almost
always the same, because then when they differ, you'll go around in circles.

>>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?").

bzr isn't an interactive program, so it handles conflicts by setting
file state.  My proposal is that BZRTAGS would not exist, except when a
conflict had been encountered.

  But, assuming that; I kinda like hiding it
> off in .bzr/ somewhere,

It's something the user should edit, so it should not be in .bzr.  It's
something they should edit now, so it shouldn't be a hidden file.

> and just have a 'bzr tag-resolve' or the like
> launch $EDITOR on it directly.

Launching $EDITOR is "implementing policy, not tools".  We need to
provide the user with the right data to solve it themselves.  This is
the pattern we follow with .BASE, .THIS and .OTHER files, and I think
it's the right thing to do here, also.

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

That's the least complicated system I can think of.  People can build
whatever process they want on top of that, just like with BASE, THIS and
OTHER files.

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

iD8DBQFEm/Fy0F+nu1YWqI0RArFDAJ9iw/MiF8+f9XJrMXS1/HpZa02Q4wCcClDy
VEWrgAbvhUtaBcRx0jifPck=
=sJHS
-----END PGP SIGNATURE-----