Re: [SCRIPT] cg-rpush & locking

[Daniel Barkalow <barkalow@iabervon.org>]

On Wed, 1 Jun 2005, Linus Torvalds wrote:

> 
> 
> 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*