1. Augie Fackler
  2. hgsubversion
Issue #393 new

Add support for 'svn move'

FlorianGeorge
created an issue

Currently, when you move/rename a file/directory using TortoiseHg and hgSubversion, one delete and one add will be performed. This breaks the svn history of a file/directory.

I would like to see support for the 'svn move' command as described here: http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.move.html

This would allow moving and renaming files with TortoiseHg + hgSubversion while preserving their full SVN history.

My current workaround is to use the TortoiseSVN Repo-Browser for move/renames, but this is of course very inconvenient.

Related issue: https://bitbucket.org/durin42/hgsubversion/issue/135/move-tracking

Comments (8)

  1. FlorianGeorge reporter

    Also, I am aware that Mercurial/Hg/TortoiseHg natively don't support history preserving move (http://stackoverflow.com/questions/5264528/why-hg-mv-mercurial-doesnt-move-a-files-history-by-default). So this could mean that a history preserving move might not be displayed correctly in hg/TortoiseHg.

    I am just asking that on the SVN Server, the correct 'svn move' is being used for move and rename, so history will be preserved on the server, and displayed correctly with an SVN client, even if this has no benefits for the user accessing the SVN Server with TortoiseHg/hgSubversion.

  2. Augie Fackler repo owner

    We should already be doing add-with-history for copies if they're recorded on the hg side. If we're not, that's strictly a bug, not an enhancement. Can you give me a shell script that shows the problem you're having?

  3. FlorianGeorge reporter

    [this post might not be relevant to this problem, just posting for reference]

    • SVNTestRepo1 Directory created
    • TortoiseSVN -> Create Repository here
    • TortoiseSVN -> Yes, Create folder structure

    • TortoiseSVN -> SVN Checkout Repository SVNTestRepo1 as SVNTestRepo2 (works)

    • TortoiseHg -> Clone Repository SVNTestRepo1 as SVNTestRepo2 (fails)

      % hg clone --verbose -- "V:\Help\Todo\130501 SVN Move in TortoiseHg\SVNTestRepo1" "V:\Help\Todo\130501 SVN Move

    in TortoiseHg\SVNTestRepo2" repository V:\Help\Todo\130501 SVN Move in TortoiseHg\SVNTestRepo1 not found [command returned code 255 Wed May 01 17:43:26 2013]

    (because of spaces in path?)

    Re-try in V:\RepoTest instead of "V:\Help\Todo\130501 SVN Move in TortoiseHg"

    • SVNTestRepo4 Directory created
    • TortoiseSVN -> Create Repository here
    • TortoiseSVN -> Yes, Create folder structure

    • TortoiseSVN -> SVN Checkout Repository SVNTestRepo4 as SVNTestRepo5 (works)

    • TortoiseHg -> Clone Repository SVNTestRepo4 as SVNTestRepo6 (fails)

      % hg clone --verbose -- "V:\RepoTest\SVNTestRepo4" "V:\RepoTest\SVNTestRepo6" repository V:\RepoTest\SVNTestRepo4 not found [command returned code 255 Wed May 01 17:48:19 2013]

    Well maybe it doesn't work with a local SVN Repo. (bug?)

  4. FlorianGeorge reporter

    Created an SVN Repository on Sourceforge: https://sourceforge.net/p/svntestrepo/

    TortoiseSVN Checkout -> H:\RepoTest\SVNTestRepo6 (works) TortoiseSVN Create File1.txt (empty) and commit TortoiseSVN Create File2.txt (empty) and commit TortoiseSVN Create File3.txt (empty) and commit TortoiseSVN Create File4.txt (with contents "asdf") and commit TortoiseSVN Create File5.txt (with contents "asdf") and commit TortoiseSVN Create File6.txt (with contents "asdf") and commit

    TortoiseHg Clone... svn+ssh://floriangeorge@svn.code.sf.net/p/svntestrepo/code/ as V:\RepoTest\SVNTestRepo7 Had to remove the "ssh" part, to actual command was hg clone --verbose -- svn://floriangeorge@svn.code.sf.net/p/svntestrepo/code/ V:\RepoTest\SVNTestRepo8

    TortoiseHg Rename File1.txt to File1Renamed.txt (command is hg rename -R V:\RepoTest\SVNTestRepo7 -vf File1.txt

    File1Renamed.txt) Commit as "Renamed File1.txt" - Commit dialog displays File1Renamed.txt green as an add "A", File1.txt as a red remove "R" (Note: For some reason, why the above green "A" entry is selected, only the "R" remove item is commited, despite both being selected. When selecting the bottom "R" remove entry instead, everything is commited - bug in TortoiseHg 2.7.2?)

    Create Directory "Directory" TortoiseHg Move File2.txt to Directory\File2.txt, using the context menu entry "Hg move versioned item(s) here" when draggin the file Commit as "Move File2.txt to Directory\File2.txt" - Commit dialog displays Directory\File2.txt green as an add "A", File2.txt as a red remove "R" (Note: For some reason, why the above green "A" entry is selected, only the "R" remove item is commited, despite both being selected. When selecting the bottom "R" remove entry instead, everything is commited - bug in TortoiseHg 2.7.2?)

    TortoiseHg Copy File3.txt to Directory\File3.txt, using the context menu entry "Hg copy versioned item(s) here" when draggin the file Commit as "Copy File3.txt to Directory\File3.txt" - Commit dialog displays Directory\File3.txt green as an add "A" (Note: This does not work, it a window opens with "No files checked - No modified files checkmarked for commit", this is why I am now doing the same with files with an "asdf" content)

    TortoiseHg Rename File4.txt to File4Renamed.txt (command is hg rename -R V:\RepoTest\SVNTestRepo7 -vf File4.txt File4Renamed.txt) Commit as "Renamed File4.txt" - Commit dialog displays File4Renamed.txt green as an add "A", File4.txt as a red remove "R" (Note: the non-committed Directory\File3.txt still showed up as the top entry in the commit window, so I kept it selected, and, as expected, the File4.txt and RenamedFile4.txt got committed, while the selected Directory\File3.txt was skipped and not committed - looks very much like an (unrelated) TortoiseHg 2.7.2 GUI Bug)

    Created a Directory\File3emptyproxy.txt, added it in TortoiseHg and committed both File3emptyproxy.txt and File3.txt, selecting the bottom File3emptyproxy.txt during commit, so both got committed successfully. Irrelevant to this Enhancement/Bug post.

    TortoiseHg Move File5.txt to Directory\File5.txt, using the context menu entry "Hg move versioned item(s) here" when draggin the file Commit as "Move File5.txt to Directory\File5.txt" - Commit dialog displays Directory\File5.txt green as an add "A", File5.txt as a red remove "R" (selected bottom red entry during commit so it worked properly)

    Created File7.txt with "asdf" content TortoiseHg Copy File6.txt and File7.txt to Directory\File6.txt and Directory\File6.txt, using the context menu entry "Hg copy versioned item(s) here" when draggin the file (Worked, had bottom entry selected)

    Created File8.txt with "asdf" content TortoiseHg Copy File8.txt to Directory\File8.txt, using the context menu entry "Hg copy versioned item(s) here" when draggin the file Commit as "Copy File8.txt to Directory\File8.txt" - Commit dialog displays Directory\File8.txt green as an add "A" (Kept first entry as selected, but this time it got committed correctly, I assume as this file, in contrast to the File8.txt has not a 0-byte, but an "asdf" content)

    Tried to push, didn't work as I had cloned the Read-Only Version with the svn:// URL, did everything again, cloning

    https://hg@svn.code.sf.net/p/svntestrepo/code/ as V:\RepoTest\SVNTestRepo8

    With the new repo, the Push went through.

  5. FlorianGeorge reporter

    Pulled everything with TortoiseSVN to SVNTestRepo7 Created File9.txt, File10.txt, File11.txt, File12.txt, File13.txt and committed with TortoiseSVN. Renamed File9.txt to File9Renamed.txt and committed. Actually this also gets committed as a delete and add. Moved File10.txt to Directory\File10.txt. Committed as a delete and add. Copied File11.txt to Directory\File11.txt. Committed as add.

    Comparing "Show Log" for:

    File1(Renamed).txt, File4(Renamed).txt, File9(Renamed).txt - History actually shows add of unrenamed file.

    (Directory) File2.txt, File5.txt, File10.txt - History actually shows add of unmoved files.

    (Directory) File3.txt, File6.txt, File11.txt - History actually shows add of uncopied files.

    So yeah, it appears that TortoiseHg/hgSubversion is correctly doing history preserving Rename/Move/Copy.

    As of why it didn't appear this way in my production environment, I can have a look at tomorrow, but my guess is probably a not-checked "Stop on copy/rename" checkbox on the computer there.

  6. yyjdelete

    Tested with hgsubversion 691078c +Mercurial version 2.7.2(from TortoiseHg 2.9.2) 1.create an normal svn xx

    2.clone xx to an new hg yy

    3.cd yy

    4.echo 123 > file1

    5.hg commit -A

    6.hg copy file1 file.cp

    7.hg rename file1 file.rn

    8.hg history see last changeset id

    9.hg status -C --change id

    A file.cp
      file1
    A file.rn
      file1
    R file1
    

    10.hg push

    11.clone xx to an new hg zz

    12.cd zz

    13.hg status -C --change id

    A file.cp
    A file.rn
    R file1
    

    The rename info is already lost(also lost in svn)

    but if rename in svn, hg can get the info

  7. maugustin

    Excactly as yyjdelete writes: After using hg rename the history is preserved in the local hg repo, but after pushing into svn via hgsubversion and looking at the log history in svn, it's broken in svn. Something is not correctly send in the commit to the subversion server during push the hg change with the rename.

  8. Log in to comment