views:

39

answers:

1

Is svn-rebasing-and-pushing from multiple clients to the same Git repo vulnerable to race conditions if both clients try to svn-rebase and push concurrently?

Here's more info: I'm setting up a GitHub-hosted mirror of an SVN project. To do the mirroring, I'll run this cron job every few minutes (per this article):

git svn rebase
git.exe push origin master

For redundancy, I'd like to have another server running the same cron job. But will this break in the face of race conditions like these?

  • Both servers rebase at almost the same time. One will git push the changes and the other will try to push the same changes.
  • One server rebases, then there's an SVN checkin, then the other server rebases and quickly pushes the new checkin, then the first, slower server tries to push one checkin behind.

It's desired if the later operation simply returns a no-op (aka "Everything up-to-date"). It's also OK if the conflicting push fails, as long as if its cron job runs again later at a non-conflicting tmie, then it will work OK.

What's not OK is if the local repo on either server can get into a failed state where manual intervention is needed. If that kind of failure is possible, how should I change the commands above to make them self-recovering?

+2  A: 

I don't think you will run into any particular problems doing this. Pushing into a bare repository with Git by default disallows non-"fast-foward" pushes, so if there were to be any kind of conflict then that push would fail temporarily. (The next one, if there is no conflict at that time, would succeed.)

These situations should be easy for you to test manually, by running sequences like:

Instance A            Instance B
----------            ----------
git svn rebase
                      git svn rebase
git push
                      git push

and

Instance A            Instance B
----------            ----------
git svn rebase
                      git svn rebase
                      git push
git push
Greg Hewgill
I think you mean "Pushing into a bare repository with Git by default disallows NON-'fast-foward' pushes." :-)
ebneter
@ebneter: Good catch, thanks!
Greg Hewgill
Thanks @greg, sounds right.
Justin Grant