Issue #3600 resolved

shelve generates conflicts if eol extension enabled (with Mercurial 2.9)

Anonymous created an issue

I've created a shelve which has created the following patch for a file:

@@ -515,7 +515,7 @@
                 }
                 else
                 {
-                    Log_c.ReportWarning("Temperature controller not ready - temperature reading not available for positional compensation");
+//                    Log_c.ReportWarning("Temperature controller not ready - temperature reading not available for positional compensation");
                 }
             }

If I close the shelve dialog, re-open it and then re-apply the patch, it files giving me the option to edit the rejected file.

The shelve edit dialog highlights line 515 in the editor (the first line). The contents are identical so I don't understand why the patch couldn't automatically be applied. Could it be due to line endings?

I run on Windows 7 x64 with TortoiseHg 2.11. I have the eol extension enabled with the following in my .hgeol file

[patterns]
** = native

So the files are stored in hg with LF line endings but converted to CRLF on check-out.

In the shelve editor, if I enable EOL visibility in the patch window, it shows line endings of LF but the working copy file I can edit will be in CRLF.

Could this be why the apply shelve failed and I had to manually edit the file?

I've had this problem occasionally with prior versions of TortoiseHG and it's made the shelve tool fairly unusable as I often have to manually edit files when applying shelves and I've not been able to work out why.

So now I'm wondering if it's due to an EOL issue as I'm guessing not everyone has the EOL extension set up as we do.

Thanks

Comments (18)

  1. 536886

    Sorry, the patch wasn't formatted correctly. This is the patch contents:

    @@ -515,7 +515,7 @@
                     }
                     else
                     {
    -                    Log_c.ReportWarning("Temperature controller not ready - temperature reading not available for positional compensation");
    +//                    Log_c.ReportWarning("Temperature controller not ready - temperature reading not available for positional compensation");
                     }
                 }
    
  2. Yuya Nishihara

    Probably it was caused by #3595.

    Because the view isn't refreshed after shelving, you can easily move the same chunk twice. Then, "unshelve" will complain the latter chunk cannot be applied correctly.

  3. 536886

    I'd seen this issue but I'm not sure it's the same. I create the shelve, close the shelve dialog and check that the commit pane is showing no local modifications, then re-open the shelve window and try to re-apply the shelve and it fails. Unless THg is trying to apply it twice, as I don't believe I was as have checked this sequence a couple of times.

  4. 536886

    I've just checked the shelve file and there are no duplicate lines. Is there a page which describes how to apply hot fixes? I've not done this before.

  5. 536886

    The shelve tool definitely has a problem with line endings when 'eol' extension is on. As mentioned, we have our .hgeol file set to

    [patterns]
    ** = native
    

    So that files are stored in the repository using LF but checked out on Windows using CRLF. I've been using kdiff3 to look at the state of line endings prior to and after shelving.

    1. Revert all changes in working copy
    2. Modify Lid.cs in visual studio
    3. View diff in kdiff 3 - shows both files have DOS line endings
    4. Select repository | Shelve ...
    5. Select the modified chunk
    6. Click the delete selected chunk button.
    7. When prompted to 'Revert all file changes', select NO
    8. Close the shelve window

    There seem to be 2 issues. Firstly, THg has reverted the chunk even though 'No' was selected.

    Secondly, the file is still marked as modified but with no visible changes. If you then view the file diff in kdiff3, it shows the parent as having DOS line endings but the local file now has Unix line endings.

    It does appear that 'Shelve' doesn't use the correct line endings as specified by the EOL extension under certain conditions. I suppose this could be related to THg using it's own 'Shelve' implementation, #3545

  6. 536886

    I've just tested with sourcetree 1.4.1 using thg's 2.9 mercurial and it can shelve and unshelve the change with no problems and leaves the line endings as DOS as expected after unshelving. But it appears to be using hg's shelve.

  7. Yuya Nishihara

    Thanks for the detail. I couldn't reproduce the original issue with eol extension, but it might be related to #588 and http://thread.gmane.org/gmane.comp.version-control.mercurial.tortoisehg.user/3341/.

    FWIW, if no one in your team does not use Linux or Mac, the best thing is to avoid eol extension. See http://mercurial.selenic.com/wiki/FeaturesOfLastResort.


    how to apply hot fixes

    Add the following lines to Mercurial.ini (Settings -> Edit File):

    [extensions]
    thgissue3595 = path/to/hgext/thgissue3595.py
    
  8. 536886

    I've tried the patch and it fixes the refresh issue of the file and chunks list, however if a chunk was selected, the 'delete chunk' button was enabled and is still enabled even after the list clears so doesn't look like it's refreshing the toolbar. A minor issue but just though I'd mention it.

    However it doesn't help with either of the issues I'm seeing here, either re-applying a shelve or with the differing line endings after deleting a chunk. I believe it is related to to #588 as prior to 2.11, quitting and re-starting thg would allow the shelve to be applied but since 2.11, this doesn't help either so something appears to have changed with this release.

  9. 536886

    FWIW, if no one in your team does not use Linux or Mac, the best thing is to avoid eol extension

    The repository was imported from Git and was set up in this way so unless there is a way to convert the repository (without loosing history) so that internally all the files have CRLF line endings then we're stuck with EOL.

  10. Yuya Nishihara

    Thanks, now I can reproduce this on Linux.

    It always happens with Mercurial 2.9, but not with 2.8. I'll look into changes between 2.8 and 2.9 later.

    the 'delete chunk' button was enabled and is still enabled even after the list clears

    This seems also caused by eol issue.

  11. Log in to comment