You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Glenn A. Thompson" <gt...@cdr.net> on 2002/05/02 03:09:38 UTC

[Fwd: svn modules (was Re: Features and release dates)]

Darn it.  I keep forgetting to send my posts to the list.
Sorry folks.

"Glenn A. Thompson" wrote:

> Hey,
>
> "Ronald V. Simmons" wrote:
>
> > Ok time to quit being a lurker..
> >
> > > Unfortunately, symlinks in the repo aren't enough. I believe that Subversion
> > > will be more multiple-repository-prone than CVS. As an example:
> > >
> > > The ASF has one CVS repository, which contains modules for each project:
> > > httpd-2.0, apr, and apr-util to name a few. However, in SVN land, I believe
> > > we're have a separate SVN repository for each project. I think the projects
> > > will want their own directory organization (trunk, branches, tags, whatever)
> > > and their own (partitioned) set of log messages / revision changes.
> > >
> > > As a result, cross-repository "modules" are quite important for SVN. It also
> > > means that when the ASF switches over to SVN, we can set up a "module" for
> > > Subversion that references the ASF SVN repositories.
> >
> > This actually raises a question I've been trying to figure out the answer to for a while now:
> >
> > I need to control access to the repository at a finer grain than the documentation would indicate is possible. In the example gstein mentions, it's as if I need one set of committers for for httpd-2.0 and another for apr and another for apr-util, with all the sets disjoint.  Since SVN is currently lacking the module linking capabilities outlined above, I've placed all my modules in one repository and arranged my directory structure in a globally efficient manner... But the problem remains that anyone who can commit in one directory can commit in all and I have yet to find a combination of  LOCATION tags which will let me limit write access to subdirectories in the repository.
> >
> > (I'm authenticating against OpenLDAP if that matters).
> >
> > any ideas greatly appreciated.
>
> I'm guessing this is where ACLs will become a topic of great discussion.
>
> gstein mentioned, in a recent thread regarding developing a SQL backend:
>
> >Yes, we'll definitely be keeping the BDB support in the code. SQL will just
> >be an option, although you may *need* it for some advanced features (for
> >example, real ACL support). But we'll certainly "gracefully degrade" if the
> >underlying DB can't perform certain types of storage or queries.
>
> I began to read all sorts of things into this.
> So I asked:
> >The ACL you speak of:
> >Is this for Repository access or a property of documents in the repository?
> >If it's for Repository access, I would love to hear more of your thoughts on this.
> >My own Authentication/Authorization schemes in past projects have left much to be
> >desired.  I have never been satisfied with anything I've brewed up.
>
> I haven't heard anything I figured it was a stupid question.  Or at the very least, poorly worded.
> I was reading 7.2.1.2 page 47 of the Subversion design document.  It discusses "svn_authorize" Does this function exist?
> I guess I'll go check......  I couldn't find it.  I look again later.
>
> gat
>
> >
> >
> > rvs
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: dev-help@subversion.tigris.org