[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Re: Re: svn commit: rev 3010 - trunk/notes

From: Justin Erenkrantz <jerenkrantz_at_apache.org>
Date: 2002-08-23 00:20:48 CEST

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.

> One or the other please, mixing the concepts will just confuse users to
> no end.

Users? What users? =)

> 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.

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...

> If you want WC item file permissions assigned based on the ACL in the
> Subversion repository, but only in terms of user only read-onlyness. I'm
> so with you. If you want WC item file permissions assigned based on
> group memberships, and other ACE related issues, I think we begin to
> enter fuzzy non-portability land. The Subversion repository ACL -> WC
> item file permission mapping needs to be very simple, and very portable.

Agreed. -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 23 00:21:20 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.