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

[rupert.thurner]

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. how did you avoid the status change when updating the
keyword?

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

rupert.