Obviously, locking it up for the duration of a build and running tests
is impractical -- but that's asking for more than what you get with
svn anyway. In fact you could emulate the svn way of things in a
stupid way by creating a new clone, applying your changes and push
from there. It won't make you happy since you might break other code,
but that's essentially what svn allows you to do by committing to your
directory when there were changes elsewhere in the meanwhile...
There are of course other solutions to this -- like splitting the
repository to multiple ones and connect them as submodules, etc, but
these all seem too much for now, and probably for a while.
Finally, I plan to look into some ways to make it easier to push
individual changes, but I now think that it's better to finish the
plain git writeup and then deal with the nightly build. (And again,
if you want to completely test changes that you push, then *nothing*
will help there, not even switching back to subversion...) (Well,
nothing except for magically optimizing things so a full build + tests
takes 2 minutes.)
On May 7, Robby Findler wrote:
> I've generally wanted to lock it for the time it takes me to make a
> build. So that doesn't seem so good.
>
> Robby
>
> On Fri, May 7, 2010 at 1:20 PM, Eli Barzilay <e...@barzilay.org> wrote:
> > BTW, another way to solve this, given that people who can push can
> > do this kind of a "DOS attack" is to add a server command to lock
> > the repository. The gitolite version that I'm using on the server
> > is already making sure that requests are properly serialized, so
> > adding a lock facility would be trivial. (Even something
> > sophisticated, like making it possible to lock the repository for
> > only N minutes.)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_________________________________________________
For list-related administrative tasks:
http://list.cs.brown.edu/mailman/listinfo/plt-dev
