Re: [SCRIPT] cg-rpush & locking

[Tony Lindgren <tony@atomide.com>]

* Linus Torvalds <torvalds@osdl.org> [050602 07:50]:
> 
> 
> On Thu, 2 Jun 2005, Tony Lindgren wrote:
> > 
> > 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.
> 
> I don't think the locking is a _huge_ issue - the only real problem I had
> with locking with BK was that readers could block a writer (ie I couldn't
> push to my public tree if there were people downloading from it), and git
> doesn't have that problem. I only push to trees that are my private ones
> anyway.
> 
> The real reason I'd prefer to not do locking is that _if_ the remote tree
> is actually more than just a CVS-like "public repository", ie if somebody
> actually does _development_ in the remote tree (hey, it may be crazy, but
> git makes this usage pattern possible), then we should eventually plan on
> having all of the regular "git-commit-script" and "git-pull-script" etc
> _also_ do locking, since they also change HEAD.

Or perhaps a more likely scenario would be automated pulls from other trees
running as cronjobs on the remote server.

> And that's going to be a lot easier if we only do a cmp-xchg and fail at
> the end (this concurrent change and "remote repo" usage is really quite
> wrong, since it basically mean that you consider somebody's development
> tree to be "public", and that's not what git is all about, but whatever..)
> 
> But this is not a huge issue. The most important thing is to make sure
> that the new HEAD is written last, regardless, so that at least local
> readers (including things like "fsck" that can take a _loong_ time) always
> see consistent state.
> 
> > 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.
> 
> Me personally, I want ssh as a major option. There are tons of machines 
> (every single of my own ones) that I use that don't let anything but ssh 
> through.

Yeah I prefer ssh too in general. Many corporate firewalls don't allow
ssh through though.

> But having alternatives is good. But ssh should be the first and primary 
> one, since it also means that there can't be any new security issues (ie 
> you won't be opening up any new holes by installing git on the remote 
> machine).

Yeah. Doing it as cgi also has some issues getting the file
permissions right so the repo would still work for ssh users too...

Is anybody planning to work on this? I'm pretty much out of
time and will probably be happy with the rsync script for now.

Tony