EOL extension

[Martin Geisler]

Mark Hammond <mhammond at skippinet.com.au> writes:

> On 1/12/2009 11:33 AM, Martin Geisler wrote:
>
>> Still I'm trying to create a new extension to help you, all based on
>> a vague idea that is should work "similar to Subversion"...
>
> I appreciate that - but please understand I am trying to help you to
> help me :)

That is great, and as Dirkjan said, it's very much appreciated :-)

>  I don't quite get how you can concede you don't understand our
> problem while also proposing you know how to fix it and reject ideas
> born from practical experience with both the problem and various
> solutions (and attempted solutions) to it.

I'm sorry if I rejected your suggestion, that was not the intention.

I've just pushed a change to the extension that will make it ignore
files containing NUL bytes (our definition of binary files). That means
that you can now put

[patterns]
** = native

in .hgeol to have all text files checked out with native EOLs.

Files are converted to the repository-native format on commit, and as
long as a file has consistent EOLs, it will go smoothly. I believe that
matches the behavior of Subversion.

>> I think *now* is the time where you -- as a Python developer --
>> should grab the code and play with it. We're talking about 170 lines
>> of code in total, of which many are comments. The Mercurial code base
>> is quite readable and we'll be more than happy to answer questions.
>
> I did.  I cloned and installed it, then read the docs and started to
> think about how I can use it with the hg-based project I work on every
> day.  I'm the only Windows developer on this project, and the text
> editors my colleagues use are dumber than the ones I use, so mixed EOL
> chars in a single file is not unusual.  [...]

I see. Could you see if the extension does what you want now that it
should be safe to apply the native filter to all files? (I write
"should" instead of "is" since I guess there could be a "binary" file
out there without any NUL bytes -- but then we're again discussing the
heuristics).

>> Please don't wait until I and the other Unix hackers have come up
>> with something that seems to work on our systems. We need Windows
>> developers to drive this, that is the only way to make this extension
>> really good!
>
> I'm trying to explain how I see that happening - but the reply seems
> to be either "but you don't need that" or "but we should theoretically
> make it easier and better".  Contrary to what some may believe, I'm
> not here just to whine - I *really* want a usable extension for this
> purpose as it is something I need to work around nearly every day.

Yeah, we need a smooth way to handle this, agreed!

Please report the problems you see using the new extension. In which
scenarios is it complaining too much, when is it not complaining
enough...

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20091201/eb325656/attachment.pgp>