EOL extension

[Colin Caughie]

I think this is a great development, and hope to be able to test and/or contribute. We have been using win32text up to now, and for the most part it's fine for us (at least since 1.3), but this looks a lot better.

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

This sounds ideal. The main problem we have with win32text, however, happens when someone forgets to enable the extension, e.g. when they join the team or get a new PC. We have developers that work remotely, in a different time zone, who often push several changesets at once. If they've messed up their line endings it can be a painful process to correct the situation, as in general they are not Mercurial afficionados and need support from myself.

It seems that this would still be a problem with the new extension, because we would still be relying on each user to enable the extension in their .hgrc/mercurial.ini file. But I can't see a way out of that without modifying the core hg code.

The ideal scenario would of course be to eventually integrate this functionality into the core package (obviously it wouldn't do anything if you didn't have a .hgeol file) but I would anticipate some resistance to that idea. The only other idea I can think of would be to have some way for a repository to indicate that it requires a certain extension to be enabled before it can be used, and for hg to disallow commits until it was.

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

The biggest issue I can see looming is that of applying patches. Prior to 1.3, nothing that applied patches would work if you had win32text enabled, meaning that we just couldn't use import, mq, transplant, shelve, etc. I pushed hard for this to be fixed in 1.3, and although the fix that went in wasn't the one I submitted, it basically works for us. My solution was to use the repo filters when patching so that it works just like everything else, but for some reason I don't quite understand mpm et al didn't like that idea.

My concern now is that I don't think the fix that *did* go in will sit nicely with the new extension, because the eol extension has its configuration in the repository (which I agree is absolutely the best place for it) but the patch.eol configuration is per-user or per-machine. Moreover there would be no obvious way to make the patching code honour the pattern-based rules you have in .hgeol.

Unfortunately I can't see any way of addressing this in the extension without changing the way core hg does patching, i.e. to make it use the repo filters as I originally proposed. And frankly I find the thought of opening that argument up again somewhat daunting...

Colin


Latest News at: http://www.indigovision.com/news2009.php