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

Re: Re: [PATCH] Add svn:permissions support

From: Justin Erenkrantz <jerenkrantz_at_apache.org>
Date: 2002-08-22 02:00:09 CEST

On Wed, Aug 21, 2002 at 04:48:26PM -0700, Bill Tutt wrote:
> If you want more, write a wrapper that sets a property, or a mechanism
> to record/restore that information on your own. I mean that's what
> Subversion properties are meant to be for anyway. User and/or project
> specific properties.

You can't easily manage the permissions of the working copy as SVN
itself trounces the permissions willy-nilly. It uses APR_OS_DEFAULT
whenever it does a copy/revert/update, etc, etc. You'd need a notion
of client-side hooks to even have a shot of implementing this.

So, no, I disagree: the SCM system needs to understand this. If
the SCM left the permissions alone, I'd agree. Subversion doesn't.

And, as my patch hopefully pointed out, the change is minimal.

> We'd have a heck of a lot more work to do for v1 if we thought we needed
> to auto-magically arbitrary OS (and indeed filesystem specific)
> properties. Whether they be NTFS parse points, Unix permissions, NT
> (D)ACLs, etc...

Low-hanging fruit. Of course, the problem is that we need to define
a portable way to define what a permission is.

Please remember that CVS respects permissions - it's an inherent flaw
in SVN's model that it can't. A working copy in CVS has at least
the same permissions as its ,v file. So, for true CVS compliance, you
need to implement something like this.

I doubt I'm the only one who has relied on the permissions feature
of CVS. So, here's a case where SVN 1.0 will not be as good as CVS
if this feature isn't present. -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 22 02:00:46 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.