re: Subversion ACLs/ WC file permissions

Let's try this again. Got bounced the first time because I forgot the
subject line.

Bill

----
Do you want a dangerous fugitive staying in your flat?
No.
Well, don't upset him and he'll be a nice fugitive staying in your flat.
 
> From: Justin Erenkrantz [mailto:jerenkrantz@apache.org]
> 
> On Thu, Aug 22, 2002 at 10:46:48AM -0700, Bill Tutt wrote:
> > No reason what so ever. However, that didn't seem like what you
wanted.
> > It seemed like you wanted a WC file's permissions set based on the
> > permissions you want the file to have, and not based on repository
> > ACL/lock state.
> 
> Who said I couldn't change my mind?  =)
> 
> I now see how a model based on a Subversion with ACLs could give
> enough knowledge to the client on how to achieve the same goal.
> As you state later, yes, it gets fuzzy.  But, that's the fun part.
> 
Heh. 
> > One or the other please, mixing the concepts will just confuse users
to
> > no end.
> 
> Users?  What users?  =)
> 
Just you apparently. :) Seriously, those non-developer types who are
checking some kind of asset into a secured repository.
> > You keep mixing up server side ACL restrictions with working copy
> > issues. I'd recommend not making the read-only WC item modification
for
> > security restriction implementations for a Subversion that doesn't
> > support ACLs.
> 
> Fair enough.  So, how about we first try to tackle supporting
> something like WebDAV ACL in Subversion?  (My one concern is whether
> anyone has tried to use WebDAV ACLs yet.)
> 
> Once that is complete (ha!), we can revisit the concept of providing
> a mechanism where the client utilizes the server-side ACLs on the
> local filesystem in *some* manner.
> 
On this we agree. Yay! :)
> I've already scratched my immediate need and it doesn't seem like
> anyone else has an even remotely similar use case, so I'm willing
> to drop it for now.  Yet, it wouldn't shock me that there *are*
> people who use it in the manner I describe or could use it -
> portability on Win32 be damned.  It just makes so much sense to me
> that it befuddles me that others don't see this.
> 
> Again, I wonder if we're too focused on only source code in the
> repository.  It'd be awesome to store installations of SW in SVN
> itself, like so:
> 
> svn co http://localhost/apache/2.0.40 apache
> *poof*  it's my 2.0.40 apache setup.
> rm -rf apache
> svn co http://localhost/apache/1.3.26 apache
> *poof*  it's my 1.3.26 apache setup.
> vi apache/conf/httpd.conf
> svn ci
> apache/bin/apachectl start
> *poof*
> 
> Those are the types of cases I'm thinking of.  And, for those, yes,
> I still think we need to be able to have fine-grained WC permission
> of entities in the repository.  Portability isn't the concern here
> (mainly because binaries are checked in) - functionality is.
> 
> Yet, no one else seems to like this, so I'll table it for now and
> focus on server-side permissions...
> 
Other people know that you can't do something this simplistic and expect
it to work with anything moderately complex. This approach just falls to
pieces to quickly. Days when you could just copy in the code as your
installation mechanism have long disappeared. You're deluding yourself
if you think it's still remotely possible. 
This process just doesn't scale well on the complexity side of things,
and on the portability side of things. I see the ease of use for your
limited case. However, it just encourages bad thinking processes in
users. The functionality isn't completely portable, and it interacts
weirdly with the requirements that the WC ACL/lock system is apt to
desire.
Even if you s/co/export in the above set of Subversion commands, I'd
still argue that it lead down the path into non-portable hell. Although,
I must admit I wouldn't yell nearly as loudly if you applied
svn:permission's to items upon a export, but not a checkout. :)
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org