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
attached mail follows:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 2 05:06:14 2002