Issue #342 wontfix

hgsubversion does not honour eol-style:native property

CloudStu
created an issue

If someone on my team sets the eol-style property to native for a given file (they use svn directly), hgsubversion checks out the file with unix-style LF endings.

The problem is I'm running on Windows, where the expected behaviour for eol-style:native is that the line endings will be checked out as CRLF. This is the behaviour if I check out the file directly through svn.

I have been able to reproduce this (on Windows) by:

creating a new svn repository

commiting a text file (with CRLF line endings)

At this stage you can clone the svn repo (I used a fully updated hgsubversion through TortoiseHg) and confirm you get the correct CRLF line endings

Using svn, set the svn:eol-style property to native on the file, and commit

Update the hgsubversion's clone, and see that the line endings have now changed to the incorrect LF

'hg version --svn' output:

hgsubversion: 055f9254d790 Subversion: 1.6.13 bindings: SWIG

Comments (8)

  1. Augie Fackler repo owner

    You can use the EOL extension that ships with Mercurial to emulate this, but it's not something hgsubversion's going to work around.

    Part of the reason for this is that we want clones to be repeatable, and fixing this would make them platform dependent.

  2. CloudStu reporter

    Ive tried it, and from what I can see, EolExtension isn't a viable solution at all.

    Every file that is set to eol-style:native is coming out of svn with a LF line ending. The EolExtension is then converting these to CRLF, causing every single file to have total file conflicts (very unhelpful when diffing). Committing back into svn won't help, as due this bug in hgsubversion, they'll just come back out with the LF endings again. I end up in a perpetual state of hg status reporting files have been modified, with diffs that tell me nothing.

    (Never mind the fact I've had to approximate through patterns in .hgeol those files that are eol-style:native, as being explicit about every file with the property set is unwieldy).

    The only reason I'm using hgsubversion is so I can use a dvcs workflow for my local work before pushing back to our central svn server. I have no need for my clones to be repeatable across platforms, as any code sharing is handled through our central repository, and all my clones are personal and local.

    In trying to make the downstream hg cloning platform independent, hgsubversion has become platform dependent for communicating with the svn server (in particular, dependent on tools that are happy with unix line endings). Surely the most important functional feature of any bridge to svn is that it is transparent, letting me use it similarly to how I would use the svn client directly. With hgsubversion, this transparency is broken, as I need to go out of my way to ensure I (and my tools) handle files with non-native line-endings correctly.

    Ultimately, I (in concert with others who access our svn repo) should be the one to decide how eol-style:native files are handled, not hgsubversion. The best solution I can think of is to make the eol-style behaviour configurable (between forcing LF, CRLF or sticking to the system's native style), with the proviso that adhering to svn's eol-style:native will make your hg clones platform dependent, whilst overriding with LF or CRLF is only reasonable if those people you will clone with are happy with potentially having the wrong style line endings (and that their tools are happy too).

    In the meantime, I'd be grateful if you could point out how I might hack around this, getting the svn update within hgsubversion to correctly use the eol-style:native property (or even just force it to use CRLF). Otherwise I'm back to the boring old svn client, waving goodbye to my hg workflow I was otherwise very happy with.

    And if this bug still won't be fixed, you should at least have a big red warning somewhere for Windows users that hgsubversion will actively disobey the svn:eol-style property when set to native.

  3. Anton Malakhov

    The bug is critical for me too. I've kind of worked around the issue with hg diff & status: 1. as eol extension recommends, "hg co -C null; hg up -C tip" eventually helps to remove false-modified files from "hg status" 2. but any local changes presented as whole file replacement by "hg diff". It can be worked around via "hg diff -b". But the side effect is that any indention changes are also ignored. :((( The fix can be on the side of 'hg diff' as well if a missing option/config would be added that ignores line endings only, but not all the spaces.

  4. Tim Delaney

    Could you check if the following patch (in --stupid mode) goes some way to fixing the issue for you? It causes --stupid mode to obey the patch.eol config setting. So setting:

    [patch]
    eol = auto
    

    should allow diffs to be applied when pulling from SVN.

    diff --git a/hgsubversion/stupid.py b/hgsubversion/stupid.py
    --- a/hgsubversion/stupid.py
    +++ b/hgsubversion/stupid.py
    @@ -200,7 +200,7 @@
                 # We can safely ignore the changed list since we are
                 # handling non-git patches. Touched files are known
                 # by our memory patcher.
    -            patch_st = patch.applydiff(ui, patchfp, {}, strip=0)
    +            patch_st = patch.applydiff(ui, patchfp, {}, strip=0, eolmode=None)
             finally:
                 patch.patchfile = oldpatchfile
                 patch.iterhunks = olditerhunks
    @@ -241,7 +241,7 @@
             backend = svnbackend(ui, meta.repo, parentctx, store)
    
             try:
    -            ret = patch.patchbackend(ui, backend, patchfp, 0, touched)
    +            ret = patch.patchbackend(ui, backend, patchfp, 0, touched, eolmode=None)
                 if ret < 0:
                     raise BadPatchApply('patching failed')
                 if ret > 0:
    
  5. Anton Malakhov

    Thank you Tim for the quick reply. After deeper look into the problem I agree that hgsubversion takes rather minor role in this EOL-hell issue. And I managed to overcome all the problems eventually.

    There were bunch of different issues: 1. my misunderstanding of what '[repository] native=' and 'CRLF' in .hgeol means 2. some issues with 'hg status' after 'hg co null; hg up' (on network drive) which masked actual problems from me. 'find -type f -exec touch '{}' \; && hg status' helps to reveal them so I'm getting consistent status for each modification of .hgeol now 3. inconsistencies in our SVN repository: some files missed eol-style:native and were stored differently. And one file had wrong encoding despite of correct eol-style but SVN agreed to commit it anyway somehow.

    So, it is not critical for me personally anymore and it does not seem like a critical bug in hgsubversion. But please consider improving user experience by automatically generating .hgeol depending on SVN internal input.

    P.S.. eol-fixing revision broke my mercurial copy.. It denied to pull aborting by "File "/users/amalakho/hg/hgsvn/hgsubversion/editor.py", line 62, in getfile raise EditingError('trying to get a popped file %s' % fname)" and when I removed .hgeol from this directory, it pulled successfully but disconnected revisions in the history.. But eventually I managed to restore working copy by means of some combination of 'hg svn rebuildmeta', 'hg up null; hg up', and moving .hgeol out of the way temporarily.

  6. terrakot

    One more hint from me, that worked in my case.

    If we set eol=CRLF for all text files explicitly (our team added it to autoprops as well), hgsubversion commits works without any EOL issues.

  7. Log in to comment