GForgin' (was: Wildcards in subversion.conf file?)

[Tess Snider <ma...@terpalum.umd.edu>]

On Wed, 22 Oct 2003, Francois Beausoleil wrote:

> You'll need mod_authz_svn for that.  Take a look at
> http://svn.collab.net/repos/svn/trunk/subversion/mod_authz_svn/INSTALL

Is that compatible with SVNParentPath?  I have heard reports that it's
not.  Can anyone confirm or deny this?

Let me explain what I'm trying to do here.  I've got a GForge repository
running on a dedicated server.  For those not familiar with it,
GForge is a lot like SourceForge (and descends from an old
SourceForge codebase).  Out of the box, GForge uses CVS.  My users are
going to be maintaining a lot of graphics and audio assets, and as we
all know, CVS doesn't handle binary files very well.  So, I'm trying to
hack Subversion support into my running GForge system.

So, here's the thought experiment:  If you suddenly had control of
SourceForge, and needed to replace CVS with Subversion, how would you
configure things?

Some requirements:
1.) Per-repository authorization.  The team on project A doesn't
	necessarily trust the team on project B (though the same user
	may be in both project A and project B).

2.) Per-repository permissions.  User X may have RW access to project A
	but only R access to project B.  Project C may be world-readable.

3.) Maximum stability.  I shouldn't, realistically, bounce the webserver
	every time a new project is added.

SVNParentPath appears to solve #3, and mod_authz_svn addresses #1 and #2,
but if they won't play nicely with each other, I'm still in a pickle.

Thanks again for everyone's quick responses!  You guys are great.

Tess

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: GForgin' (was: Wildcards in subversion.conf file?)

[Seth Falcon <sf...@fhcrc.org>]

Something that you might want to try, as an alternative to
mod_authz_svn, is using Apache's basic auth stuff with the LocationMatch
directive.

Using LocationMatch you can specify different permission schemes on a
per-repository basis (and even finer, although svn may not like that
particularly) and it should play fine with SVNParentPath.  But adding a
new project is still going to require an 'apachectl graceful' I believe,
does that count as "bouncing"?

As an aside, can anyone explain the pros/cons of using mod_authz_svn
over doing the permissions/authentication using Apache and something
like LocationMatch?  


Here's an httpd.conf snippet of what I'm talking about w.r.t. to a non
mod_authz_svn setup:

    <LocationMatch "^/svn/repos/projA">
        AuthType Basic
        AuthName "Subversion repository"
        AuthUserFile /blah/passwd
        AuthGroupFile /blah/group
        <LimitExcept GET PROPFIND OPTIONS REPORT>
            Require group projA
        </LimitExcept>
        <Limit GET PROPFIND OPTIONS REPORT>
            Require group projA
            Require group projA_readers
        </Limit>
    </LocationMatch>


+ seth


On Wed, Oct 22, 2003 at 03:58:41PM -0500, Tess Snider wrote:
<snip>
> Some requirements:
> 1.) Per-repository authorization.  The team on project A doesn't
> 	necessarily trust the team on project B (though the same user
> 	may be in both project A and project B).
> 
> 2.) Per-repository permissions.  User X may have RW access to project A
> 	but only R access to project B.  Project C may be world-readable.
> 
> 3.) Maximum stability.  I shouldn't, realistically, bounce the webserver
> 	every time a new project is added.
> 
> SVNParentPath appears to solve #3, and mod_authz_svn addresses #1 and #2,
> but if they won't play nicely with each other, I'm still in a pickle.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org