Counterintuitive tag behaviour (broken design?)

Stuart W. Marks smarks at smarks.org
Fri Mar 23 04:41:14 UTC 2007


This thread is a bit old but nobody answered Chris's questions.

Chris Quenelle wrote:
> I wrote the text after "----" first.  Then I remembered
> to ask my simple question up front.  Why should we be searching
> multiple different branches for tags?  Why aren't we just
> using the "current CS" as the complete set of tags?
> If your tree is assigned to a branch then use the branch tags.
> Otherwise use the tip-tags only.  I read the recent emails on this
> subject looking for a justification for why you need to search
> all the branches, but I didn't see one.

First, terminology. Your checked-out files are the "working copy," and the rev 
from which the working copy was checked out is the "parent rev" (what you're 
calling the "current CS"). At least, these are the terms I use.

The intent of a tag is to identify a particular node in the history tree. This 
is a property of the repository, not a particular branch or the state of the 
working copy. The parent of the working copy shouldn't matter; if you ask about 
which rev a tag refers to, the answer should always be the same regardless of 
whether the working copy has been updated to the tip, a branch, or some old rev 
in the middle of the history tree. Or, looked at the other way, it would be 
"insane" if the value of the "1.0" tag were to change if you updated your 
working copy to some rev in the past or on another branch. Thus, to find the 
right value of the tag, all branches of the repository have to be searched.

(The "insane" comment came from Linus Torvalds, in the thread "newbie questions 
about git design and features (some wrt hg)" from February. There was a 
discussion about tag behavior but unfortunately it didn't seem to come to a 
resolution. The Mercurial guys [Matt, Brendan] were talking about how tags are 
stored and propagated in the revision history, but Linus thought this implied 
that tags' values changed depending upon where you were in the history and 
called this "insane." But they don't behave this way, and everybody left the 
thread in a huff before this was resolved. Pity.)

Now there was a *bug* where the value of a tag would change spontaneously as a 
side effect of an unrelated commit, which is the subject of this thread. Matt 
integrated a fix for this (see "New tag behavior") but I have to admit I don't 
understand the new algorithm....

Your message contained some other scenarios that I couldn't quite follow. Did 
you want to discuss them further, or does the behavior make sense now? Also, 
I'd be interested in hearing about your use of hg to "maintain and resolve two 
long-term branches."

s'marks

> 
> A similar surprise came up with my use of "hg log" a few weeks ago.
> (See below the "------")  It resulted in me deciding not to use
> non-local tags until someone explained how to use them in a
> non-confusing way.
> 
> My situation might be special because I'm using hg to maintain and resolve
> two long-term branches.  So I have lots of special 'hg diff' aliases
> and I often have to use 'update' to set myself back to specific versions
> over and over again.  I might be using hg more "intensely" in this
> respect than what is normally done. (Or maybe not)
> 
> So what follows is my story...
> 
> ----------
> 
> I was surprised a few weeks ago by some strange tag behavior.
> 
> (What's the official term for "currently set/assigned CS" ?
> In other words a name for "current output of 'hg id'"
> I'll call it "current CS" for now)
> 
> I was adding some various tags to changesets and realized that
> not all my tags were showing up in "hg log" output.
> It turned out my current working CS (via update -C NN)
> was set to a CS from before I added the tags.  So later tags
> didn't show up in the "hg log" output.  But the CS's that
> were the target of the tags *did* show up (obviously).
> It doesn't make sense for a CS defined after my current CS
> to show up in the output, but a tag defined after my current CS
> to be hidden.
> 
> Of course, if I think about how it works, then it makes sense
> that the .hgtags file being used is the version from the current CS.
> But it could easily be implemented a different way.
> 
> Anyway, if you want to claim that "hg log" output is relative
> to the current CS, that's okay, but then the log output should
> only show CS's that contribute to the current state.
> (Other CS's could be hidden with a warning or something)
> Then you could have "hg log -a" show everything or something like that.
> 
> Otherwise, if "hg log" is supposed to show global output,
> then make it independent of what the current CS is, and
> use all the various .hgtags versions to attribute tags
> to CS's.  In this case you bite off the problem of establishing a
> "global tag context".  That's problem that's been discussed in
> this thread recently.  But the problem is there is no true
> "global context" because tags are applied or move *locally*
> within a changeset.
> 
> --chris



More information about the Mercurial mailing list