Is it safe to interrupt a dcommit call that appears to be hung up?

Question

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?

Answer 1

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.