On Thu, Jan 6, 2011 at 08:30, Jeff King <peff@xxxxxxxx> wrote: > > Yeah, we probably should try again. The simplest possible (and untested) > patch is below. However, a few caveats: > > 1. This patch unconditionally retries for all lock files. Do all > callers want that? I wonder if there are any exploratory lock > acquisitions that would rather return immediately than have some > delay. I don't see why not. We shouldn't be exploring to see if a lock is possible anywhere. > 2. The number of tries and sleep time are pulled out of a hat. FWIW, JGit has started to do some of this stuff for Windows. We're using 10 retries, with a delay of 100 milliseconds between each. This was also pulled out of a hat, but it seems to have resolved the bug reports that came in on Windows. We unfortunately have to do retries on directory and file deletion. > 3. Even with retries, I don't know if you will get the behavior you > want. The lock procedure for refs is: > > 1. get the lock > 2. check and remember the sha1 > 3. release the lock Why are we locking the ref to read it? You can read a ref atomically without locking. > 4. do some long-running work (like the actual push) > 5. get the lock > 6. check that the sha1 is the same as the remembered one > 7. update the sha1 > 8. release the lock > > Right now you are getting contention on the lock itself. But may > you not also run afoul of step (6) above? That is, one push updates > the ref from A to B, then the other one in attempting to go from A > to B sees that it has already changed to B under our feet and > complains? Not if its a force push. :-) -- Shawn. -- 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