EOL extension

[Martin Geisler]

Mark Hammond <skippy.hammond at gmail.com> writes:

Hi Mark

> I made a first pass at trying to use the eol extension for real.

Super, thanks for the report!

> I started with a fresh clone of an existing repository. After adding
> and committing my .hgeol file, I wondered how to convert the working
> tree to the new format - and figured I could do "hg up -r 0" followed
> by "hg up". It has since been pointed out I probably wanted '-r null',
> and although I don't get the same problem with '-r null' this problem
> seems worth reporting anyway.
>
> So starting with the fresh clone:
>
> % hg up -r 0
> 15 files updated, 0 files merged, 1926 files removed, 0 files unresolved
>
> % hg up
> 1927 files updated, 0 files merged, 14 files removed, 0 files unresolved
>
> [[ All good.  For testing, I created a .hgeol file consisting of:
> [patterns]
> **=native
> ]]
>
> % hg add .hgeol
>
> % hg ci -m "add .hgeol"
> .hgeol
> committed changeset 1136:fda353c4fd1d
>
> % hg up -r 0
> 15 files updated, 0 files merged, 1927 files removed, 0 files unresolved
>
> % hg up
>  local changed server/python/build/lib/junius/getmail.py which remote
> deleted
> use (c)hanged version or (d)elete?
>
> Note the and erroneous reporting of a local change which did not occur
> without the extension.

Right. I believe this is because the extension currently always uses
.hgeol from tip. So when you updated to revision 0 (instead of null),
the files were written out in your working copy with native file endings
and furthermore, the extension will try to convert them back to LF when
you if you had made a commit.

You can see this effect here in this newly added test:

  http://bitbucket.org/mg/hg-eol/src/tip/tests/test-eol.out#cl-206

Lines 206-219 correspond to this case: you have an old repository where
some files have LF and some files have CRLF EOLs. You then add a .hgeol
file (line 210) which asks for everything to be native. In the test,
this is done without activating the extension.

At that point the repository is inconsistent: files are still stored
with both LF and CRLF EOLs, but .hgeol demand LF for all of them (in the
repository, and native in the working copy).

After activating the extension and after issuing 'hg debugrebuildstate'
one sees that some of the files suddenly appear as modified (line 216).
The following commit synchronizes the EOLs.

Notice how the win.txt file is modified on line 217 and 226 when were
are working against a repository with LF as repo-native EOLs. If the
repository had had CRLF as it's repo-native EOL setting, then unix.txt
would appear modified (lines 241 and 250).


I believe your problem is that you also have files that appear modified
when you update to revision 0. These modifications are then to be merged
into the target revision after the the update (tip). And then things go
wrong because a file "you" modified has been deleted.

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.