EOL extension

Tue Dec 1 17:49:03 CST 2009

Paul Moore <p.f.moore at gmail.com> writes:

> I doubt that mandating use of mq will work. I'm not sure if you are
> mandating mq, or just using it as an example, but I'd probably
> understand your suggestion better if you used core Mercurial commands.
>
> I'm in agreement with Mark (I think! I may have misunderstood his point) that
>
> 1. Server-side hooks won't work, as I could commit all sorts of damage
> locally and then push, and even if the final result is clean, there
> could be any amount of clutter in between. Or would the server side
> hook stop the intermediate csets? If so, I could have work that I
> couldn't push without rewriting my local history. That's nasty. (Is
> that why you need mq above?)

I think that's why timeless used mq. But I agree, we cannot ask people
to rewrite their history. That is a fundamental difference between
Subversion and Mercurial: in Subversion it's no big deal to refuse a
commit because of bad EOLs. After all, the user can only ever have one
outstanding commit. With Mercurial the offending commit might be older.

Rewriting history is certainly possible (as timeless showed), but it
hinders effective collaboration on changes since you shouldn't rewrite
changesets that you have shared with others.

That is why I think the only sane setup is to let the hooks ensure that
the very last changeset is okay. If it isn't, the user can make a new
changeset to bring things in order.

This is really no different from how a Buildbot works: it tests the HEAD
revision of your repository, and if you see something break, then you go
fix it. You don't do repository surgery to replace the broken revision,
you make a new revision to fix it. Nothing new here... :-)

> 2. Commits to fix EOL breakage are icky. Not least because diffs that
> show lines changing but the only change is to EOL format are also
> icky. Let's aim to avoid EOL breakage getting into the repo in the
> first place.

Sure, we'll let the extension warn/refuse/complain as much as it can
when it sees broken files:

* It will currently *refuse* to commit files with inconsistent
  line-endings (just like Subversion). So if you mess up a file, you'll
  be told when you try to commit.

* It will *convert* files with consistent line-endings on commit (just
  like Subversion). That means that it is okay for an editor to
  accidentally convert the entire file, as long as it does it
  consistently.

> It seems to me that the extension (as described in its documentation -
> I haven't tried it) does what is needed for most usages. To be sure it
> works as we want, we need to understand precisely how it will be used.
> There was a proposal for how the extension would be configured for
> Python - I can't remember where it was, but that would be a good
> start: how would Python developers be expected to configure things,
> and how would working with the Python sources then look.

Good point. The goal is to end up with instructions like this:

  Enable the eol extension to ensure that line-endings are handled
  correctly and uniformly. Put the following in your ``~/.hgrc`` or
  ``Mercurial.ini`` file::

    [extensions]
    eol =

The .hgeol file will then take effect.

> Mark has some use cases that concern him. To take one, the developer
> who creates a new file with CRLF endings (because that's what his
> editor does by default) - how would that be an issue? If I assume that
> he's creating a C or Python source file, then the *.c = native or *.py
> = native setting in the standard .hgeol file contained in the Python
> repository would fix that. The only risk I can see is if it's a
> completely new type of file, not picked up by the existing rules.

Right, that would be annoying. That is why we can use catch-all pattern:

  [patterns]
  ** = native

> In that case, I guess a CRLF format file ends up in the repository.
> That's bad, but I can't quite see what the impact would be (presumably
> at some point where the .hgeol setting gets added, there'd be a cset
> which normalises all the line endings - icky, as I said above, but
> probably rare and likely not avoidable).

I don't think it will be that much of an issue. It will of course have
the greatest effect on an annotated file view. In both 'hg serve' and
'hgtk annotate' (TortoiseHg) it's easy to move back through the cleanup
changeset. In TortoiseHg you simply right click on a line and choose
'annotate parent'. That way it's super easy to move back through the
file history.

> Can we list through various other such concerns and check that the
> outcome is OK? The various cases (and the correct behaviour) would
> make a good set of tests for the extension.

Excellent idea!

> By the way, I'm a Windows developer, but the code I work on generally
> only has me as developer, and I don't hit these types of issues. I
> could probably simulate them, but so could any Unix developer (with
> the above one, you can create a CRLF file just as easily on Unix as
> Windows, it's just not the default there). So although I appreciate
> that the Unix guys want input from us Windows people, it honestly
> isn't any easier for us (on our small personal or test projects) to
> demonstrate the issues than it is for you :-)

That is true, and that is also why I've made the eol test case in such a
way that it tests all four combinations of {CRLF,LF}-repository and
{CRLF,LF}-working copy:

  http://bitbucket.org/mg/hg-eol/src/tip/tests/test-eol

-- 
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/20091202/9044f9ea/attachment.pgp>