git-svn dcommit to HTTP proxy can fail

git-svn dcommit to HTTP proxy can fail

[Ben Jackson]

git-svn dcommit turns each new git commit into an SVN commit, then uses
its normal fetch mechanism to pull the new revision back from the SVN
server.  It compares the fetched version to the git version with diff-tree.
If they don't match you generally get a very cryptic error message.

The primary reason for the mismatches seems to be SVN HTTP proxies.  When
the svn-remote is an HTTP proxy the commit is delegated to the actual
SVN server.  It acknowledges the commit as usual and then updates the
proxies with a post-commit hook.  This means that the commit+fetch combo
is often fast enough to catch the proxy in the pre-commit state and no
new revisions are fetched at all.

Someone has described this with examples on stackoverflow:
http://stackoverflow.com/questions/4238876/git-svn-fails-to-dcommit-even-after-clean-checkout

I wrote an answer to that question including a patch which adds retries
(polling the proxy until the expected revision appears).  I am currently
using that patch at work and it is a big improvement.  I keep meaning to
"productize" it and send it to this list, but there are two remaining
problems:

1.  The proxy update seems to have at least two phases: one that creates
the commit and one that sets metadata (such as author).  The new code is
pretty good at racing in and catching the new commit in an intermediate
state with the author "syncuser" (instead of me).  I don't think that
"syncuser" is a fixed name and I worry that waiting for the commit author
email address to match will break if there is any user mapping going on.

2.  My linear backoff retries total about 10 seconds, and I've blown
that budget with commits of large binaries (eg FPGA images).  You do get
a much more informative error ("New revision 1234 did not appear in
repository after 30 retries.") but it still fails.  Of course I can
increase it, but what's reasonable?

Suggestions?

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/