How to recover from an unwanted rename using git-svn: "Transaction is out of date"

Question

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?

Answer 1

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!

Answer 2

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.