You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Pierre Belzile <pi...@idilia.com> on 2004/03/25 17:43:14 UTC
Features: branch merging with "history", file level ACL
Hi,
I'm checking out subversion and have the following questions/requests:
1) Does anyone know when branch merging will go beyond CVS and actually
remember the last base for branch. To avoid re-importing the same
changes over and over again.
2) We need file level access control. (Allow the "*.h" everywhere but
block the "*.cc" for stuff provided by other groups. Any idea if this
could be done?
Other than that, subversion looks really good.
Thanks, Pierre
Re: File level ACL
Posted by Gary Feldman <ga...@memento-inc.com>.
----- Original Message -----
>From: Pierre Belzile
>My understanding is that access controlthrough the Apache interface can't
cut it. mod_auth_svn
There's an obvious alternative, which you may not like because it requires
restructuring your tree, but it has certain advantages: Put the .h files in
a separate include directory, and then use Apache's directory protections.
This is a fairly common source tree pattern. It's sometimes done for the
same reason in a different context (i.e., it's easier to manage UNIX
permissions this way). It also makes it easier to set up include flags for
the compiler (e.g. just generate automatically from all the include
directories). It makes packaging of kits easier (just include the /include
directory instead of identifying files individually). It makes it much
easier to verify that permissions are what you want them to be. It makes it
easier to have private include files (instead of using .hh or something
similar). It takes a bit of getting used to, particularly since most people
never learn this approach in school, but it's probably worth it - especially
in your case where you have such a strong requirement.
Gary
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: File level ACL
Posted by Ben Collins-Sussman <su...@collab.net>.
On Fri, 2004-03-26 at 08:43, Travis P wrote:
> On Mar 26, 2004, at 7:49 AM, Pierre Belzile wrote:
>
> > It's ironic that CVS does this. (Using proper permissions on the
> > files.) I can't move to subversion until something equivalent
> > (hopefully better!) exists.
>
> Proper for your particular standard Unix environment I'm guessing. As
> I understand it, Subversion uses APR for all filesystem access for
> great portability. Not all filesystems share the same permission model
> (Window's filesystems?), including some Unix systems.
Um, I think there's some confusion here. CVS can restrict permission on
specific files because the repository is just a bunch of RCS files. The
administrator goes in and hand-edits the permissions on *.c or *.h by
hand.
The SVN repository has only "imaginary" files in a database. There's no
concept of permissions within this virtual filesystem. Maybe someday
the database will have a real ACL system, but for now, all permissions
are controlled by programs outside the repository, such as apache or
svnserve or pre-commit hooks.
Just as Pierre suggests, a good feature to add to mod_authz_svn would be
wildcards on directory/file patterns.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: File level ACL
Posted by Travis P <sv...@castle.fastmail.fm>.
On Mar 26, 2004, at 7:49 AM, Pierre Belzile wrote:
> It's ironic that CVS does this. (Using proper permissions on the
> files.) I can't move to subversion until something equivalent
> (hopefully better!) exists.
Proper for your particular standard Unix environment I'm guessing. As
I understand it, Subversion uses APR for all filesystem access for
great portability. Not all filesystems share the same permission model
(Window's filesystems?), including some Unix systems. e.g. AFS has
per-directory ACLs only (there is a trick with symlinks so that AFS
permissions can appear to be file-based; come to think of it, the same
trick might well work for Subversion if Subversion handled symlinks; I
wish it did; creating a workaround using properties and a
client-wrapping script is something I'm going to have to do I think but
there are some inefficiencies that may be hard to get around; please
excuse this really long parenthetical...). I myself am a fan of
per-directory privileges because it's so much easier to use and manage
and avoid mistakes. I've also used IBM's DFS file system for years
which is a very full-featured combination of per-directory/per-file
ACLs plus it honors standard Unix permission bits. It's a real
nightmare to use in practice.
-Travis
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: File level ACL
Posted by "Robert M.Zigweid" <rz...@zigweid.net>.
On Mar 26, 2004, at 8:49 AM, Pierre Belzile wrote:
> Thanks for the suggestions yesterday. However, no solutions were
> offered. For a recap:
> dir1/aClass.h (should be readable to all users of the library)
> dir1/aClass.cc (should only be visible to selected users working
> on it's library)
>
> Users of the library cannot view the source code in aClass.cc. They
> can only read aClass.h. Library developpers can r/w everything.
>
> My understanding is that access controlthrough the Apache interface
> can't cut it. mod_auth_svn uses a datafile that can contain
> directories only. My suggestion would be to add file patterns as well.
> For example, I would say "*.h" is "r" for "*".
>
> It's ironic that CVS does this. (Using proper permissions on the
> files.) I can't move to subversion until something equivalent
> (hopefully better!) exists.
>
> Cheers, Pierre
I would actually probably prefer to take it one step further and allow
wildcards in general in this list. As well as limiting file access, it
would be convenient to be able to have some permissions such as
/*/branch/ type permissions where the * would represent a project
(using the /projectA/trunk style structure).
Just a thought.
--
Robert M. Zigweid rzigweid@zigweid.net
http://rzigweid.zigweid.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
File level ACL
Posted by Pierre Belzile <pi...@idilia.com>.
Thanks for the suggestions yesterday. However, no solutions were
offered. For a recap:
dir1/aClass.h (should be readable to all users of the library)
dir1/aClass.cc (should only be visible to selected users working on
it's library)
Users of the library cannot view the source code in aClass.cc. They can
only read aClass.h. Library developpers can r/w everything.
My understanding is that access controlthrough the Apache interface
can't cut it. mod_auth_svn uses a datafile that can contain directories
only. My suggestion would be to add file patterns as well. For example,
I would say "*.h" is "r" for "*".
It's ironic that CVS does this. (Using proper permissions on the files.)
I can't move to subversion until something equivalent (hopefully
better!) exists.
Cheers, Pierre
Re: Features: branch merging with "history", file level ACL
Posted by Eric Gillespie <ep...@pretzelnet.org>.
"Sander Striker" <st...@apache.org> writes:
> The pre-commit hook doesn't allow for read-access restrictions.
As i hope its name makes obvious :). We were talking about
commits, not reads.
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Features: branch merging with "history", file level ACL
Posted by Sander Striker <st...@apache.org>.
> From: epg@gould.diplodocus.org [mailto:epg@gould.diplodocus.org]On
> Behalf Of Eric Gillespie
> Sent: Thursday, March 25, 2004 9:26 PM
> No, it was a sarcastic one, though the sarcasm apparently did not
> translate. The RA layer is a GOOD THING. That's one of the
> reasons i think the pre-commit hook solves the access control
> better than mod_authz_svn.
The pre-commit hook doesn't allow for read-access restrictions.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Features: branch merging with "history", file level ACL
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Brian Mathis <bm...@directedge.com> writes:
> Ben Collins-Sussman wrote:
>
> >On Thu, 2004-03-25 at 13:25, Eric Gillespie wrote:
> >
> >
> >> Why do we
> >>bother to support multiple RA methodss at all?
> >>
> >>
> >
> >You're right, Eric. SVN should strive to be as rigid and inflexible as
> >possible. :-)
> >
> >
> >
>
> In all honesty, that question is a fair one.
No, it was a sarcastic one, though the sarcasm apparently did not
translate. The RA layer is a GOOD THING. That's one of the
reasons i think the pre-commit hook solves the access control
better than mod_authz_svn.
For now, anyway. Where's that ACL subsystem? :)
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Features: branch merging with "history", file level ACL
Posted by Brian Mathis <bm...@directedge.com>.
Ben Collins-Sussman wrote:
>On Thu, 2004-03-25 at 13:25, Eric Gillespie wrote:
>
>
>> Why do we
>>bother to support multiple RA methodss at all?
>>
>>
>
>You're right, Eric. SVN should strive to be as rigid and inflexible as
>possible. :-)
>
>
>
In all honesty, that question is a fair one. It's not a question of
technicality or flexibility, but one of management. Supporting multiple
methods creates confusion (as has been seen many, many times on this
list), and also reduces supportable features to the least common set.
How many support questions and feature requests would be so much easier
if one only had to deal with svnserve?
--
Brian Mathis
http://directedge.com/b/
Re: Features: branch merging with "history", file level ACL
Posted by Ben Collins-Sussman <su...@collab.net>.
On Thu, 2004-03-25 at 13:25, Eric Gillespie wrote:
> Why do we
> bother to support multiple RA methodss at all?
You're right, Eric. SVN should strive to be as rigid and inflexible as
possible. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Features: branch merging with "history", file level ACL
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Pierre Belzile <pi...@idilia.com> writes:
> I understand that this works for directory but not for files
> within the directory. I should have said that the "*.cc" and
> "*.h" are in the same directory.
That's OK, the pre-commit hook is better for this than
mod_authz_svn anyway. Why everyone always recommends the less
flexible and ra-dav-dependent method is beyond me. Why do we
bother to support multiple RA methodss at all?
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Features: branch merging with "history", file level ACL
Posted by Pierre Belzile <pi...@idilia.com>.
I understand that this works for directory but not for files within the
directory. I should have said that the "*.cc" and "*.h" are in the same
directory. For example:
dir1/aClass.h (should be visible to all users of the library)
dir1/aClass.cc (should only be visible by selected users working on
it's library)
Cheers,
On Thu, 2004-03-25 at 12:47, Ben Collins-Sussman wrote:
> >
> > 2) We need file level access control. (Allow the "*.h" everywhere but
> > block the "*.cc" for stuff provided by other groups. Any idea if this
> > could be done?
>
> Use apache's mod_authz_svn module for this. Read about it in chapter 6.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
Re: Features: branch merging with "history", file level ACL
Posted by Ben Collins-Sussman <su...@collab.net>.
On Thu, 2004-03-25 at 11:43, Pierre Belzile wrote:
> Hi,
>
> I'm checking out subversion and have the following questions/requests:
>
> 1) Does anyone know when branch merging will go beyond CVS and
> actually remember the last base for branch. To avoid re-importing the
> same changes over and over again.
Someday. Needs a long design discussion first.
>
> 2) We need file level access control. (Allow the "*.h" everywhere but
> block the "*.cc" for stuff provided by other groups. Any idea if this
> could be done?
Use apache's mod_authz_svn module for this. Read about it in chapter 6.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Features: branch merging with "history", file level ACL
Posted by John Peacock <jp...@rowman.com>.
Pierre Belzile wrote:
> 1) Does anyone know when branch merging will go beyond CVS and actually
> remember the last base for branch. To avoid re-importing the same
> changes over and over again.
svk has this now, at the expense of having a local private SVN repository.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org