restricting keyword expansion consistently to working dir

[Christian Ebert]

Hi Jesse,

* Christian Ebert on Thursday, January 10, 2008 at 10:59:27 +0100
> * Jesse Glick on Wednesday, January 09, 2008 at 09:35:32 -0500
>> By the way, did you consider using encode/decode hooks instead of a 
>> separate command to expand keywords? This would be more like what CVS 
>> does (for better or for worse). E.g.
>> 
>> [decode]
>> ** = expand:
>> [encode]
>> ** = unexpand:
>> 
>> where you would want to automatically skip over binary files (those 
>> which contain NUL).
>> 
>> 'hg cat' and 'hg di' work on the unexpanded versions, which is probably 
>> what you want; the keywords would just get expanded in the working copy.
>> 
>> An irritation is that Hg does not permit encode/decode hooks to be 
>> composed, so for Windows usage you would to add 'expandwithcrlf' and 
>> 'unexpandwithcrlf' variants.
> 
> I thought about this some more, and perhaps -- I have to actually
> /try/ these things to see if they work -- I'll get a more
> consistent approach by wrapping wread, wwrite, wwritedata in my
> repo subclass and grabbing repo.workingctx at reposetup.

I came quite a long way and liked it, less code, a bit cleaner.
But! It fails for "hg up -C" and "hg revert", because I haven't
found a way -- except by parsing args for these cases, and then
falling back on the filelog based method. Not good.

The problem is: how do I get the info to what node the working
dir will be updated to.

I've attached a copy of my what I tried and failed, so if you
want to have a look at it, and come up with a solution, you're
welcome ;-)

c
-- 
_B A U S T E L L E N_ lesen! --->> <http://www.blacktrash.org/baustellen.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: keyword.py
Type: application/x-python
Size: 17190 bytes
Desc: not available
Url : http://selenic.com/pipermail/mercurial-devel/attachments/20080111/d1bcfe7d/attachment.bin