10

I'm using git-svn. I've moved file 'A' to 'B' and I'm up to date with the svn HEAD (using git svn rebase). I can commit all other changes without problems. Now I've decided that I want to move 'B' back to 'A' and commit that change.

When I do the move and commit to my local master it works fine, but I get the following when doing a git svn dcommit:

Transaction is out of date: Out of date: 'A' in transaction '3652-1' at /opt/local/libexec/git-core/git-svn line 570

So I tried to copy and delete in a separate commit which resulted in:

Item already exists in filesystem: File already exists: filesystem '/usr/svn/db', transaction '3652-1', path 'A' at /opt/local/libexec/git-core/git-svn line 4735

I've recovered from this situation with plain svn by using the workarounds like the one described in the documentation, but I don't know how to recover with git-svn. What is going on and how do I fix it?

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
iwein
  • 25,788
  • 10
  • 70
  • 111

3 Answers3

8

Removing .git/svn did not work for me. Instead, here's how I resolved:

  • Deleted the offending directories from the repository (But I'm not sure that this is necessary. In hindsight I think I could have skipped this step)
  • git svn rebase
  • During the rebase, there were some conflicts. For each conflict, I resolved the conflicts in text editor, then used git add <file-in-conflict> and then git rebase --continue
  • After rebase completed successfully, git svn dcommit ran successfully!
Upgradingdave
  • 12,916
  • 10
  • 62
  • 72
4

I can't claim to understand what's really going on under the hood in git-svn in this case (although the underlying SVN issue makes perfect sense). My usual strategy when git-svn gets confused somehow is to blow away the .git/svn metadata directory (as in this post). This almost always saves me from odd synchronization issues between the git and SVN repositories.

Community
  • 1
  • 1
Dave Goodell
  • 2,143
  • 16
  • 18
  • Thanks for the input. Could you provide a little detail on how the svn issue makes perfect sense? I'll try to reproduce it and see if blowing away the .git/svn directory works. I vaguely recall that I actually did a fresh clone and the issue was still there. – iwein Dec 01 '10 at 19:55
  • It looks like an issue of a "mixed revision" working copy, where some part of the working copy has been updated to a different, older revision than the rest of the WC. But I can't really tell which parts are out of date. This is partly described here: http://svnbook.red-bean.com/en/1.5/svn.basic.in-action.html#svn.basic.in-action.mixedrevs. Did the metadata removal trick work for you? – Dave Goodell Dec 02 '10 at 19:37
  • I didn't manage to test it anymore due to the volatility of my local code bases. Let's assume that it works until someone finds that it doesn't :) – iwein Dec 24 '10 at 17:58
  • I'm getting the same "Item already exists", but unfortunately, this didn't work for me. I'll add an answer if I find a work around – Upgradingdave Aug 21 '12 at 13:33
0

It happened with me when I interrupted the dcommit process.

Follow these steps to recover from error:

  1. git svn rebase
  2. You will get conflicts in files. Resolve the conflicts & then git add filename (in which conflict occurred) for each file.
  3. Now do git svn dcommit. It will be pushed to remote successfully.
fedorqui
  • 275,237
  • 103
  • 548
  • 598
Sachin Tiwari
  • 1
  • 1