7

I'm using the git-svn bridge and have reshuffled a large number of files around in my repository so it's organized a bit better.

I ran git svn dcommit to put the changes back at the SVN server and the process appears to be hung up. I'm getting no CPU use and no network use for the dcommit call for the past 45 minutes. The output is stuck at:

> git svn dcommit
...snip...
     R       zlib/vs2005/zconf.h => tools/zlib/vs2005/zconf.h
     R       zlib/vs2005/zlib.h => tools/zlib/vs2005/zlib.h
     R       zlib/vs2005/zlib_ds.lib => tools/zlib/vs2005/zlib_ds.lib
     R       zlib/vs2005/zlib_ds.pdb => tools/zlib/vs2005/zlib_ds.pdb
     R       zlib/vs2005/zlib_s.lib => tools/zlib/vs2005/zlib_s.lib
     R       zlib/vs2005/zlib_s.pdb => tools/zlib/vs2005/zlib_s.pdb

And that's where it's been for about 45 minutes now.

Edit: it eventually ended saying the HTTPS connection timed out. This took about an hour and a half to happen.

I can't seem to find any definitive information on what will happen if I interrupt this dcommit call and what I'd need to do before I attempt to resubmit the changes again from my local repository back to the SVN server.

I can answer one part of my question: What would I need to do before trying again?

After the connection timed out and my prompt was returned I had to do a git svn fetch before I could run git svn dcommit again. All of my rename operations were found in the SVN repository but directories that were left empty after the shuffle were not deleted. I had to use my SVN client to remove them. I'm not sure if this a git-svn thing or because of the HTTPS timeout during that dcommit call.

I still don't know the answer to: Is interrupting a dcommit call safe?

Ian C.
  • 3,783
  • 2
  • 24
  • 33
  • 1
    If you want git-svn to remove empty dirs, you should use the `--rmdir` command line option or `svn.rmdir` configuration option. – ninjalj Nov 15 '10 at 20:55
  • As for your main question, you should probably ask on the git mailing list, possibly CC'ing git-svn's author. – ninjalj Nov 15 '10 at 20:56
  • Thanks @ninjalj -- I'll try on the mailing list. – Ian C. Nov 15 '10 at 20:56
  • If you get an answer, please don't forget to post it here. (I'll be happy to up-vote.) I've wondered the same questions myself. – gotgenes Nov 15 '10 at 22:13

1 Answers1

5

Yes, it is safe.

dcommit basically does this for each commit you are pushing to SVN:

  1. Compute the difference between the commit and its parent. (Essentially, creating a patch for the commit.)
  2. Send this difference over the SVN protocol as a changeset to be committed. Once this is complete, the commit now lives on the SVN server.
  3. Fetch the new commit, and any other new commits that were created in the meantime by other users, and store them locally as proper Git commits. The git-svn branch ref will be updated to point to the latest one.
  4. Rebase all the commits after the one just processed onto the git-svn branch ref being committed to. (Since the commit being processed should now live on the server, this will result in the local commit that was just processed being discarded, as per any other rebase.)

If you interrupt during step 2 (which is what it sounds like) then the current commit will be aborted on the svn server. You should be able to dcommit again without worry.

But, if you are paranoid (and you should be when interoperating between VCSes like this) you may want to run git svn rebase first. This will pull down any new commits on SVN (including the commit that you tried to push, if it actually succeeded server-side) and rebase your local branch on top of it.

cdhowie
  • 158,093
  • 24
  • 286
  • 300
  • Thanks @cdhowie. After the timeout finally returned my prompt I did try a rebase. Wish I'd grabbed the error I got from it. It wasn't willing to update my local git repo from the SVN server. If I can recreate it I'll post the error. – Ian C. Nov 16 '10 at 20:46
  • It was a conflict, but I couldn't figure out how to resolve it. I ended up verifying the commit using `svn` and then recreating the local git repository from scratch with another `git svn clone` call. – Ian C. Nov 17 '10 at 14:57
  • Accepting this answer because it does indeed answer my question: dcommits are safe to interrupt in that they don't leave SVN in a bad state, but they may leave the SVN/git bridge in a bad state. – Ian C. Nov 17 '10 at 14:58
  • They should not leave the bridge in a bad state either. It sounds like there was just a conflict with someone else's SVN activity? – cdhowie Nov 17 '10 at 15:19
  • Also, as a side note, any damage done to the bridge should be repairable with some rebase magic... – cdhowie Nov 17 '10 at 15:25