[merge] tags in repository

[Matthew D. Fuller]

On Thu, Jan 25, 2007 at 02:49:52PM -0600 I heard the voice of
John Arbash Meinel, and lo! it spake thus:
> 
> I agree that versioned, independent from revisions, tags are good.

+1 from me too.

However, y'know what's even better than really powerful and capable
tags someday?  Usable and sufficient tags now.  Unversioned repo-wide
tags are pretty much what every other DVCS has and works fine with.
I'd like more capability than that, but this conversation sure does
get old:

    "Hey, $OTHER_DVCS has tags.  Does Bazaar?"

    "No."

    "Why not?"

    "$OTHER_DVCS's tags have $PROBLEM.  We wanna solve that by
     $STRATEGY."

    "Oh.  Cool.  So how do I do that?"

    "You don't.  We don't have it yet."


It seems like a capability that we can add later, without handicapping
ourselves much by adding the 90% solution now.  And we do need tags.
Really.


> And Martin has a reasonable concern about complicating the mental
> model that users have to understand.

I think it can potentially make the model pretty simple, actually.
Unlike code etc., you're probably not going to dig through tag history
very often, and the merge cases tend to be much more straightforward
and automagic[0]; the history would mostly be used to DTRT when it
comes to moving tag changes around between branch/repo's; manually
poking through it is more an "ohcrap" recovery strategy, than a
standard workflow.


[0] Actually, I tend to reflexively think that this is one place that
    the 'smarter' merge types can really strut their stuff in
    understanding what the user probably 'wants' in any given
    situation and ancestry, without running into some of the troubles
    you can get using those methods with code.  But that's just a
    feeling.


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