EOL extension

[Martin Geisler]

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

> On 30/11/2009 10:42 PM, Martin Geisler wrote:
>> Mark Hammond<mhammond at skippinet.com.au>  writes:
>
>>> Being "easier than subversion" is an excellent goal, but we
>>> shouldn't let a good assertion get in the way of actual experience
>>> ;) In this particular case, that one developer who knows the pattern
>>> list needs to be updated may not be the same developer who adds the
>>> new file.
>>
>> Is that a big problem? I don't think it is if we make it easy to
>> correct mistakes.
>>
>> I think we should aim for a simple mechanism that get's it right 99%
>> of the time. Simplicity is important here in order to make it easy to
>> correct mistakes.
>
> Where has the 99% come from? Wherever it came from, it is still less
> than the 100% subversion has been offering. I can't recall when I have
> ever had to fix such a mistake created by subversion.

We're talking about configuring Subversion like this:

  [miscellany]
  enable-auto-props = yes

  [auto-props]
  * = svn:eol-style=native

as per your link to zope.org?

I believe that can go wrong too. According to their FAQ, Subversion is
also using a heuristic where a binary file must contain a NUL byte or
contain more than 15% non-ASCII printing characters within the first
1024 bytes:

  http://subversion.tigris.org/faq.html#binary-files

The FAQ also says that you can set svn:eol-style on binary files, though
I am not able to reproduce that here with Subversion 1.6.3:

  http://bitbucket.org/mg/hg-eol/changeset/1dc734e6af11/

We've normally used a stricter check in Mercurial, namely by searching
for a NUL byte anywhere in the file. I would say that this makes

  [patterns]
  ** = native

safer than in Subversion (unless you have files that match the 15%
non-ASCII printing character criteria).

> I've a concern that this is justified as sounding good *in theory* -
> much like win32text sounded good *in theory*. Using something which is
> actually proven as a model seems to offer the best chance of success,
> particularly if the people designing the model aren't actually part of
> the target user-base. Assertions such as "99%", "better than", "easier
> than" etc all sound like falling into the same trap.
>
> Recall the huge amount of energy which went into explaining why
> win32text didn't work in practice.

I'm still curious about that -- the biggest problem is that it must be
configured by every user instead of relying on in-repo rules, right?

You may say that I "don't get it" and you would be right. I honestly
think people (developers!) should upgrade to one of the many free
editors on Windows that understand LF just fine.

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"...

> Many people simply could not get past the fact they thought it
> *should* work fine and without any experience to prove otherwise,
> communicating this fact was very difficult and tedious. I was hoping
> to inject some real experience into the discussion to ensure the same
> problem doesn't also happen in this case. That seems to be distracting
> more than it is helping - as do all my attempts at helping with this -
> so I'm happy to leave you guys to it and once some real Windows
> developers start making noise that it does indeed work, I'll look
> forward to becoming yet another happy user.

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.

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!

-- 
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/8656a3c8/attachment.pgp>