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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Thu Jun 02 17:34:11 2005
This archive was generated by hypermail 2.1.8 : 2005-06-02 17:34:12 EST