Re: [SCRIPT] cg-rpush & locking
- From
Daniel Barkalow <barkalow@iabervon.org>
- Date
- Jun 2, 2005, 06:39 UTC
- Message-ID
- <Pine.LNX.4.21.0506020223570.30848-100000@iabervon.org>
- In-Reply-To
- <Pine.LNX.4.58.0506011951150.1876@ppc970.osdl.org>
On Wed, 1 Jun 2005, Linus Torvalds wrote:
Show 33 quoted lines
> > > On Wed, 1 Jun 2005, Thomas Glanzmann wrote: > > > > 1. acquire remote lock > > 2. get remote HEAD > > 3. if remote HEAD is ahead (not included in our history) abort > > and free lock. > > 4. push objects > > 5. update remote HEAD with local > > 6. free remote lock. > > You really need a specialized client at the other end, because regardless > of locking, you want to write the objects atomically (ie download them > into a temp-file, and then do the "rename" thing to make them show up > all-or-nothing). > > Also, I'd suggest a slight modification to avoid keeping the lock for a > long time, namely to have the lock protect just a quick "compare and > exchange". So the algorithm would become: > > 1. read remote HEAD > 2. if remote HEAD isn't in our history, abort with "remote is > ahead" > 3. calculate the objects needed to push locally > 4. push them (but accept the possibility that the remote may > already have them, so have the protocol able to say "got that > one already"). Make this use the atomic write on the other end. > 5. do an atomic compare-and-exchange of the remote head with the > new one (ie only switch the remote HEAD if it still matches > what we were expecting it to be) > > Hmm?
If the lock is only to protect against someone else modifying HEAD after we've checked that it is our starting point and before we modify it, there's no reason not to hold the lock while pushing; it wouldn't block anything other than someone doing a quick push in the middle of our long one, and thereby causing us to dump a lot of useless objects on the server (which will become obsolete as we will need to do the merge and push a different version).
The key is that people can still download the old version until the new version is there, regardless of the lock; they'll get data about to go stale, but they would have anyway had they been a few seconds earlier. The main annoyance would be that you'd be blocked from pushing, and then have to poll for the other upload to finish before you'd be able to pull, do the merge, and then push your changes; you want to have the client watch for the resolution of the other transfer one way or the other, since you're in the current state precisely because you lost on getting the lock and now definitely need the next version.
-Daniel *This .sig left intentionally blank*