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@xxxxxxx> http://www.ben.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html