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

[Christian Ebert]

Hi Rupert,

* rupert.thurner on Sunday, June 14, 2009 at 02:36:39 -0700
> On Jun 12, 7:17 pm, Christian Ebert <blacktr... at gmx.net> wrote:
>> * Christian Ebert on Sunday, June 07, 2009 at 15:44:38 +0200
>>> Could you test the attached simple patch which enables keyword
>>> expansion when running "hg convert"?

Upon further investigation -- it takes me awhile because I use
the extension in quite a different manner -- I do not think this
patch is needed.

>>> I disabled this for security reasons, and am not sure what the
>>> ramifications are, so be careful and do not use it on production
>>> code ;-)
>> 
>>> I did some testing with cvs, and it seemed to work; once you
>>> update after converting you have hg hash Id's. No need for any
>>> special hooks. Those might be needed however when you go back to
>>> cvs, I don't know.

For convert the way it works is like this:

$ hg convert cvsrepo cvsrepo-hg

no acting on keywords here, because the working directory is not
changed and keyword expansion only happens in the working
directory.

$ cd cvsrepo-hg

now there are 2 possibilities:

a) you have [keyword] files and [keywordmaps] configured globally
   (slightly dangerous because of inadvertent expansions)

   $ hg update
   
   keywords are expanded in the working directory

b) you /must/ configure [keyword] files and [keywordmaps] for
   cvsrepo-hg; once this is done
 
   $ hg update

   keywords are expanded in the working directory
 
>> a) With keyword expansion enabled for "hg convert" I think there
>>    is no problem with updates stemming from "hg convert"

Actually working with keyword.py as is.

>> b) If there are still problems with empty commits this might be
>>    because of a workflow like the following (I use an example I'm
>>    actually experimenting with):
>> 
>>    I convert the Vim cvs directory.
>>    No prob with the change from cvs to hg keywords.
>> 
>>    I update the runtime files via rsync (their cvs release cycle
>>    differs from more frequent updates on the Vim ftp site).
>>    Here I run into the "empty commit problem", because some files
>>    differ only by having cvs instead of hg keywords.
>> 
>> For b) a solution/workaround is to run something like:

this was buggy, try:

#!/bin/sh
for f in `hg st -mn`
do
    # diff w/o context
    # remove diff header
    # remove line ranges
    hg diff -g -U 0 "$f" | \
    sed -e '1,3 d' | \
    grep -v '^@@ .* @@$' | \
    grep -v -E '\$(Revision|Author|Date|RCSFile|Source|Id|Header): .+ \$' > /dev/null 2>&1
    if test $? -eq 1; then
        # only lines containing keywords found
        echo "reverting $f"
        hg revert --no-backup "$f"
    fi
done

>> I will try to implement a something like it as an extra command
>> in keyword.py, like "hg kwcleanup" or "hg kwupdate". No garanties
>> if this will ever make it into main. Once I've got it working,
>> sortof, it would be nice if you could test it.

The only way I can think of these "empty commits" can happen is a
use case like the above. I.e., the files in question do not stem
from a "proper convert" but were copied manually (rsync in the
above case) from somewhere else into the working directory.

Strictly speaking this is not something for the keyword extension
to cover.

> with pleasure. as the problem exists in daily work, would there be a
> possibility to somehow enable it by default so that one has not to run
> it constantly?

Are you sure that this can't be solved by enforcing a clean
convert policy? That is, do not copy files around manually but
either work in cvs _or_ hg, and then convert?

Are you also sure that [extensions], [keywoword], [keywordmaps]
were properly configured before running "hg update" after
conversion?

I think the above script or a python equivalent can only be a
repair script/extension, not part of keyword.py.

keyword expansion in cvs/svn and hg will always work in a
different way, the most visible indication being the changeset
hash, but more importantly due to fundamental differences between
a centralized and a distributed scm.

So, atm it looks to me like you have to adjust your daily
workflow a bit, bearing in mind that you switch between two
different scm architectures. For emergency cases the above script
should be fine.

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/
                          http://www.blacktrash.org/underdogma/index-en.html