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

[Christian Iversen]

On Tuesday 23 May 2006 22:26, Diego Biurrun wrote:
> 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.

Ok, no problem then :-)

-- 
Regards,
Christian Iversen