[Python-Dev] Mercurial migration: help needed

Martin Geisler mg at lazybytes.net
Sun Aug 30 20:37:36 CEST 2009


"Martin v. Löwis" <martin at v.loewis.de> writes:

>> So the extension should do that: either abort commits with the wrong
>> EOL markers or do as Subversion and automatically convert the file in
>> the working copy.
>
> Maybe I misunderstand: when people use the extension, they cannot
> possibly make mistakes, right? Because the commit that gets aborted is
> already the local commit, right?
>
> Of course, it may still be that not all people use the extension.

Exactly, when people use the extension, they wont be able to make bad
commits.

> I think this is of concern to Mark (and he would like hg to refuse
> operation at all if the extension isn't used), but not to me: I would
> like this to be a feature of hg eventually, in which case I don't need
> to worry whether hg enforces presence of certain extensions.

Yes, that would be nice for the future. I don't know if the other
Mercurial developers will see this as a big controversy -- Mercurial has
so far made very sure to never mutate your files behind your back.
Expansion of keywords (like $Id$) is also implemented as an extension.

> If people make commits that break the eol style, we could well refuse
> to accept them on the server, telling people that they should have
> used the extension (or that they should have been more careful if they
> don't use the extension).

Indeed. Their work will not be lost -- one can always take the final
file, convert the line-endings, copy it into a fresh clone and commit
that. With more work one could even salvage the intermediate commits,
but that is probably not necessary.

> I think subversion's behavior wrt. incorrect eol-style is more subtle.
> In some cases, it will complain about inconsistencies, rather than
> fixing them automatically.

Okay --- I don't have much experience with the svn:eol-style, except
that I've read about it in the manual.

-- 
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: 196 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20090830/97bf28be/attachment.pgp>


More information about the Python-Dev mailing list