Tag keyword (keyword extension)

[Christian Ebert]

* Benno Dielmann on Sunday, July 13, 2008 at 19:37:15 +0200
> On Sunday 13 July 2008 Christian Ebert wrote:
>| * Benno Dielmann on Sunday, July 13, 2008 at 13:33:14 +0200
>|> Yes, I know how tagging works in Mercurial. But since creating a tag is
>|> followed by a normal commit, the repository gets a new changeset number.
>|> So why doesn't it appear in the expanded Revision keyword?
>| 
>| Because "hg tag" changes .hgtags and refers to the revision in
>| question. The keyword $Revision$ refers to the changeset the file
>| containing the keyword was last changed.
>| 
>| I don't think what you want can be implemented:
>| 
>| "hg tag" sort of looks (points) *back* to a change.
>| 
>| How can the extension guess at a certain commit that this commit
>| will be tagged (in the future) and what the tagname will be?
>| 
>| Plus, the keyword extension works *filewise*, whereas the
>| tag has its meaning *repowide*. So your operation would have to
>| update all `hg kwfiles` ... doable, expensive, but when and with
>| what tagname?
> 
> Slooowly my brain seems to adapt to the Mercurial way of thinking... ;-)
> 
> So, $Revision$ expands to the changeset number of the changeset when the file 
> containing the keyword was changed, not to the number when the whole project 
> was changed ("parent")...

Yes.

Because the keyword extension doesn't think the Mercurial way ;)

To quote the comment at the beginning of keyword.py:

# Keyword expansion hack against the grain of a DSCM
#
# There are many good reasons why this is not needed in a distributed
# SCM, still it may be useful in very small projects based on single
# files (like LaTeX packages), that are mostly addressed to an audience
# not running a version control system.
#
# For in-depth discussion refer to
# <http://www.selenic.com/mercurial/wiki/index.cgi/KeywordPlan>.

keyword.py works more CVS-like, or *filewise*; whereas the true™
Mercurial way thinks repo-wise.

> Funny enough, I got the "tag" thing to work, by adding 
> 
> [keywordmaps]
> Tags = {tags}
> Revision = {node|short}
> 
> to my .hgrc. 
> 
> Now, $Tags$ expands to $Tags: [the tags] $ when I update to the revision 
> actually bearing the tag(s) (not the revision when .hgtags was committed), 
> just as I liked it to be. 
> 
> But only if the file containing the keywords was actually changed for the 
> revision that was tagged...

Yes. I don't think {tags} is a useful keywordmap.

> Well, I guess there is no way to have keyword expanded even if the containing 
> file wasn't changed...?

You could do that with a different kind of extension -- or a
hook. But afaics it wouldn't work with "hg tag" as that only
writes to .hgtags. Even if you hooked into the tag command you
would have to commit those "expansion" /afterwards/.

>| update all `hg kwfiles` ... doable, expensive
> 
> What do you mean by "expensive"? 

All files configured for keyword expansion would have to be
searched for eg. $Tags$ and overwritten if $Tags$ was found.

But, again, imo it wouldn't make any sense. If really want
something like this, run a script that "expands" $Tags$ in all
files to the tag you /want/ to give; commit that change; tag.

>| You might consider whether the keyword extension is the right
>| tool for what you want, and whether this is not better
>| implemented via some hooks.
> 
> I haven't looked into hooks until now. 

Have a look at the link above. I really think it's useful.

c
-- 
  Was heißt hier Dogma, ich bin Underdogma!
[ What the hell do you mean dogma, I am underdogma. ]

_F R E E_  _V I D E O S_  -->>  http://www.blacktrash.org/underdogma/