eol with hg 1.4.x?

[Martin Geisler]

Brett Cannon <brett at python.org> writes:

> On Tue, Jan 5, 2010 at 13:29, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
>
>> On Tue, Jan 5, 2010 at 22:22, Martin Geisler <mg at lazybytes.net> wrote:
>> >> We're going live with Mercurial 1.4.x in 10 days... am I better off
>> >> sticking with win32text for now, and switching to eol in the future?
>> >
>> > I think so -- the eol extension is neither here nor there :-( I don't
>> > have a very clear image of what is still missing.
>> >
>> > It would be very helpful if you could try out the current code and help
>> > hack on it. I'll be busy writing my dissertation in the next two months
>> > so I cannot (should not) spend a lot of time on it :-(
>>
>>
> Once I am done with my PyCon presentation prep (which might not be until
> PyCon =) this is my top open source priority.
>
>
>>  I have one particularly sticky bug in hgsubversion to fix, when I
>> manage to get that done (I've only been hacking on it for a few
>> months...) I want to put out an updated python hg conversion along
>> with the eol extension and see what the Python guys think. That might
>> solicit some useful feedback...
>
> If Martin thinks the extension is feature-complete (at least in the
> spec),

The wiki page has become quite sprawling:

  http://mercurial.selenic.com/wiki/EOLTranslationPlan

But the main plan is still to ignore EOLs as much as possible when
applying patches and when updating. I've just added a test for the
update case:

  http://bitbucket.org/mg/hg-eol/changeset/45bbb6fee863/

One can see that the deleted line is carried over by the 'hg update'.

I was actually not sure this worked, but it seems okay... another recent
change is that the .hgeol file is now read from the working directory
directly. This means that changes to .hgeol are seen immediately in the
form of files marked as modified. With that, the main TODO has been
cleared.

> I say we make sure the extension is rock-solid and then Python makes
> the switch regardless of what others want in terms of new features.
> The people who brought up this issue have had quite a while to follow
> the work and be active participants.

Well said :-)

> I am quite comfortable with saying that people have until the release
> of Mercurial 1.5 on July 1 (since the extension depends on that
> version) to get any changes in, but that will be the date Python hits
> the switch. Otherwise we make the switch much sooner (shortly after
> Mercurial 1.4 is out?) and say if people want/need to use the
> extension they need to run Mercurial from a specific branch.
>
> I am comfortable with either solution. How about the rest of you?

I guess we have a sort of chicken-and-egg problem here. Nobody wants to
use the extension before it's done, and it wont be done until people
have used it... So I'm unsure about how to best move along, but I guess
people should try it out some more.

-- 
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/attachments/20100106/098f9caf/attachment.pgp>