Steven Grimm <koreth@xxxxxxxxxxxxx> wrote: > Junio C Hamano wrote: > >Steven, I do not interact with real svn repository myself so I > >can only judge from the test in this patch and Steven's test > >case, so it would be more assuring for me if you can confirm it > >fixes the issue for you. > > > > It seems to; I can't make the problem happen any more. I am slightly > concerned -- but I don't know libsvn well enough to say for sure -- that > this doesn't actually *eliminate* the problem, but rather tightens the > window of opportunity down to some very small amount of time. Which is > certainly an improvement, of course! > > Maybe only Eric can answer this, but from a cursory inspection, it > doesn't look like it actually locks the modified files before generating > the patch to apply. Is there still a possibility of losing a change that > hits the svn repository in the middle of git-svn dcommit running? Or > does locking happen implicitly somewhere I'm not seeing? (Again, I > haven't combed the code deeply, so it's entirely possible I've missed > something.) The commit runs as a transaction on the server-side, where all the real locking occurs. SVN supports user-side locking (svn lock), but it is only advisory and can be taken/unlocked by other users (svn lock/unlock --force). When SVN::Git::Editor is instantiated in commit_diff() (line 853), the 'r' parameter passed to it is the revision we'll generate our diffs against. Before, we were generating diffs against the latest revision. We generate diffs against 'r' in SVN::Git::Editor::M() (line 3339) and SVN::Git::Editor::chg_file (line 3383) passing the $fbat baton object (which represents the file at revision 'r') around. -- Eric Wong - 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