[Ffmpeg-devel] CVS --> Subversion conversion, test repository

[Diego Biurrun]

On Tue, May 23, 2006 at 03:31:22PM +0200, Christian Iversen wrote:
> On Tuesday 23 May 2006 15:16, Diego Biurrun wrote:
> > On Tue, May 23, 2006 at 01:30:37PM +0200, Christian Iversen wrote:
> > > On Tuesday 23 May 2006 11:58, Diego Biurrun wrote:
> > > > On Tue, May 23, 2006 at 01:16:10AM +0200, Christian Iversen wrote:
> > > > > On Tuesday 23 May 2006 00:35, Diego Biurrun wrote:
> > > > > Advantages:
> > > > >
> > > > > - Much, much easier to administer for several users
> > > >
> > > > Why would that be?  svnserve configuration is not complex at all, while
> > > > Apache problems can be devilish to debug.
> > >
> > > Well, I don't agree completely there, but then again I set up apache
> > > configurations for $$ :-)
> > >
> > > Also, the subversion extension to apache allows much more fine-grained
> > > control over user permissions. For instance, you could give a new
> > > developer write access only to /trunk/somelib for a while, before giving
> > > him rw on /trunk.
> >
> > You can do that with svnserve as well.
> 
> Really? I'm confused then. This is from svnbook:
> 
> "Notice that svnserve only understands ???blanket??? access control. A user either 
> has universal read/write access, universal read access, or no access. There 
> is no detailed control over access to specific paths within the repository. 
> For many projects and sites, this level of access control is more than 
> adequate. However, if you need per-directory access control, you'll need to 
> use Apache instead of svnserve as your server process."

svnserve allows this via pre-commit hooks.

In any case we don't need this, we run with full write privileges for
all committers.  Restrictions are handled on the social interaction
level.  So far this is working quite well.

Diego