Re: [SCRIPT] cg-rpush & locking

[Tony Lindgren <tony@atomide.com>]

On Thu, Jun 02, 2005 at 09:14:53AM +0200, Matthias Urlichs wrote:
> Hi,
> 
> Daniel Barkalow:
> > 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 objects we push aren't going to be obsolete. The server needs them
> anyway, because our HEAD refers to them.

I don't think locking for the duration of the push really is a problem.
It is unlikely that there would be so many people pushing that it would
cause inconvenience... Of course it would be nice to optimize it if
possible.

> What if the connection dies in the middle of a push? You then sit there
> waiting for it, and the lock, to time out. OTOH, an atomic cmpxchg on
> the server can't block and can't timeout.
> 
> > 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.
> > 
> I disagree. Given that you need to wait for the upload to finish anyway
> (whether you know it or not ;-) it makes sense to spend the time
> actually uploading -- upload speed is frequently lower than download
> for individuals.

I would assume the biggest problem for most people is how they can push
through a firewall. From that point of view it would make sense to do
the push as a cgi script rather than something over ssh. And with a
cgi script you can of course optimize the locking and use tmp files
before renaming which are a bit hard to do with rsync.

Tony