{"thread":{"id":"26321","subject":"git-svn dcommit to HTTP proxy can fail","startedAt":"2011-01-22T19:58:17Z","lastAt":"2011-01-22T19:58:17Z","messageCount":1,"participants":["Ben Jackson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"159790","messageId":"20110122195816.GA12162@kronos.home.ben.com","threadId":"26321","inReplyTo":null,"subject":"git-svn dcommit to HTTP proxy can fail","fromName":"Ben Jackson","fromEmail":"ben@ben.com","sentAt":"2011-01-22T19:58:17Z","receivedAt":"2011-01-22T19:58:17Z","isPatch":false,"sender":{"key":"ben@ben.com","avatar":"https://gravatar.com/avatar/df49904dd23b03a5f57d9d53c0bf9fb6f69a14fac075c98f54f26cf1ce960794?d=mp&s=160"},"body":"git-svn dcommit turns each new git commit into an SVN commit, then uses\nits normal fetch mechanism to pull the new revision back from the SVN\nserver.  It compares the fetched version to the git version with diff-tree.\nIf they don't match you generally get a very cryptic error message.\n\nThe primary reason for the mismatches seems to be SVN HTTP proxies.  When\nthe svn-remote is an HTTP proxy the commit is delegated to the actual\nSVN server.  It acknowledges the commit as usual and then updates the\nproxies with a post-commit hook.  This means that the commit+fetch combo\nis often fast enough to catch the proxy in the pre-commit state and no\nnew revisions are fetched at all.\n\nSomeone has described this with examples on stackoverflow:\nhttp://stackoverflow.com/questions/4238876/git-svn-fails-to-dcommit-even-after-clean-checkout\n\nI wrote an answer to that question including a patch which adds retries\n(polling the proxy until the expected revision appears).  I am currently\nusing that patch at work and it is a big improvement.  I keep meaning to\n\"productize\" it and send it to this list, but there are two remaining\nproblems:\n\n1.  The proxy update seems to have at least two phases: one that creates\nthe commit and one that sets metadata (such as author).  The new code is\npretty good at racing in and catching the new commit in an intermediate\nstate with the author \"syncuser\" (instead of me).  I don't think that\n\"syncuser\" is a fixed name and I worry that waiting for the commit author\nemail address to match will break if there is any user mapping going on.\n\n2.  My linear backoff retries total about 10 seconds, and I've blown\nthat budget with commits of large binaries (eg FPGA images).  You do get\na much more informative error (\"New revision 1234 did not appear in\nrepository after 30 retries.\") but it still fails.  Of course I can\nincrease it, but what's reasonable?\n\nSuggestions?\n\n-- \nBen Jackson AD7GD\n<ben@ben.com>\nhttp://www.ben.com/\n"}]}