Line ending translation extension

Christian Ebert blacktrash at gmx.net
Thu Sep 10 21:28:43 CDT 2009


* Martin Geisler on Friday, September 11, 2009 at 01:43:30 +0200
> I was looking at the keyword extension tonight and it occured to me that
> it does everything we want: it can expand and shring keywords (convert
> to/from native format). It overrides lots of commands to ensure that
> this is done correctly.
> 
> We're currently trying to make do with the encode/decode filters -- I
> wonder if this is because the keyword extension makes things more
> complicated that they are, or if we will also need to do this?

I think the decode/encode way would be conceptually cleaner and
less intrusive for keyword expansion as well, but I simply didn't
find a way to make it work in practice.

I made several attempts to go "the hook way" for keyword
expansion (pretxncommit, update etc.) but they all failed in the
end, the main reason being that keyword expansion needs
information per file ("against the grain of a DSCM"), and very
specific information on top -- simply put, it needs the
equivalent of "hg log -l 1 <file>" of the point in history the
working directory is updated *to*, every time this is done.
Basically file-wise information I was not able to obtain via
encode/decode hooks. Which meant jumping through hooks of an
entirely different nature, like detecting the command that is
currently run etc.

Whereas, as far as I understand, the topic here is more about how
to get the working directory into a state depending on the
current OS. Whatever you read from the changelog, the outcome
should be either CRLF, LF, CR (Mac?). You also don't have to
bother about stuff like "hg archive" etc. The information you
want to obtain at hook time seems more managable: again you only
want CRLF, LF etc., not possibly date, changeset id, commit
message etc.

The simplified alternatives are:

1) encode/decode knows exactly *whether* to decode/encode, in
   what _way_ to interpret filelog.read.

2) pluging into filelog (keyword extension) knows more about
   *what* to interpret from filelog.read, but less about whether
   to decode (expand)/encode (shrink) or simply do nothing; to
   detect whether we are in a decode or encode or no hook so to
   speak.

So, for your purposes, you might have more chances to succeed the
encode/decode way.

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
Next show: 18 September 2009 --->>    http://goldkante.org/
         --->> http://www.blacktrash.org/underdogma/ccc.php


More information about the Mercurial-devel mailing list