hg status, hg diff do not consider an enabled keyword extension --> leads to empty commits

[Christian Ebert]

* rupert.thurner on Saturday, June 06, 2009 at 00:19:21 -0700
> On 5 Jun., 22:34, Christian Ebert <blacktr... at gmx.net> wrote:
>> * rupert.thurner on Friday, June 05, 2009 at 10:00:09 -0700
>>> we are using mercurial as client to cvs or svn. for some files we use
>>> keywords why we switched on the keyword extension. we update parts of
>>> the keywords also with other means. unfortunately, hg status, hg diff
>>> do not respect this and show "modified" or a diff:
>> 
>>> hg init ts
>>> cd ts
>>> echo "\$Id\$" > kw.java
>>> hg add
>>> hg commit -m "kw demo"
>>> hg kwexpand
>> 
>> not needed
>> 
>>> echo "\$Id\$" > kw.java
>>> hg diff
>>> diff -r c3b9388a091a kw.java
>>> --- a/kw.java   Thu Jun 04 22:05:23 2009 +0200
>>> +++ b/kw.java   Thu Jun 04 22:10:16 2009 +0200
>>> @@ -1,1 +1,1 @@
>>> -$Id: kw.java,v c3b9388a091a 2009/06/04 20:05:23 o... at notpossible.com $
>>> +$Id$
>> 
>>> this then leads to mercurial not allowing expanding / shrinking the
>>> keywords before committing. a commit then is empty as there the
>>> keyword extension seems to work.
>> 
>>> is this a bug, or do we misuse the extension?
>> 
>> Hm, I can see that this is a problem when you change only the
>> expanded keyword.
>> 
>> Showing the diff could be avoided, but there would still be a
>> status change and therefore an empty commit. So this way, at
>> least the status change is also reflected in the diff.
>> 
>> So far I've only considered the cases where you don't
>> fiddle with the expanded keyword manually. I don't know whether
>> it's possible to make "hg status" see such a file as clean; plus
>> this is potentially quite dangerous.
>> 
>> I'll think about this when my head is clearer (which might never
>> happen ;-) )
>> 
>> Am I right in the assumption that you want hg see cvs-formatted
>> $Id$'s as no change to the files in question so you can easily
>> switch between "cvs" and "hg" versions of the same file?
> 
> that was the reason, yes - your head is to clear :) we use cvs or svn
> to check out from the central repository, and hg locally to branch/
> merge. a cvs update in some cases updates the hg-hash to a cvs version
> number. i could also imagine an option that hg does not update the
> keyword at all ... but i am unsure if this also leads to a status
> change for hg.

In theory you should be fine if you run "hg kwexpand" after every
cvs/svn update. Do you convert via "hg convert"? If yes, then
again in theory, this could be automated with a post-command
hook.

[in theory there is no difference between theory and practice ;-)]

I will try the above with a converted vim repo, perhaps that
gives me some ideas.

> how did you avoid the status change when updating the
> keyword?

By tweaking the dirstate to "clean" for the files in question.
Very dirty and dangerous ;-)

> i guess it takes some time until we can convince our users to use
> different concepts to mark a version of the file.

Perhaps a similar hook, but running "hg kwshrink", is needed when
going back to cvs/svn.

If you're patient with me perhaps we can find perhaps not an
ideal but workable solution. As its source docs state, the
keyword extension sort of goes against the grain of a DVCS
(because it works per file, not per changeset), and
certainly any purist wouldn't touch it with a barge pole; see
<http://www.selenic.com/mercurial/wiki/KeywordExtension>. The
main use cases I wrote it for were small projects and
distribution to users who do not run *any* VCS. But let's
investigate what is doable in practice.

c
-- 
\black\trash movie    _C O W B O Y_  _C A N O E_  _C O M A_
Ein deutscher Western/A German Western
-->> http://www.blacktrash.org/underdogma/ccc.html
-->> http://www.blacktrash.org/underdogma/ccc-en.html