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

Re: File permision portability

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-10-10 19:37:49 CEST

On Tue, Oct 09, 2001 at 02:43:10PM -0500, kfogel@collab.net wrote:
> Yah -- it sounds like whatever Subversion comes up with as a portable
> representation for file modes, most of the new code should actually
> end up in in APR. Subversion will limit itself to storing and
> retrieving those representations as svn properties, and of course to
> actually using them to set perms when appropriate (checkout, update).

Hmm... I think SVN should only worry about the "execute" bit. That is really
the only interesting mode. For r/w, we should just use 0666 as modified by
the current umask.

Consider what happens if we attempt to record unix permissions precisely:

1) User A has set a restrictive umask based on local policy. SVN screws him
   because it ignores his umask, making everything world readable (which was
   the policy on User B's machine, who checked in those files).

2) User B is checking files out into a directory for use by a web server. He
   wants everything to be world readable. But SVN obeys the permissions from
   A and checks out stuff with -rw------- perms.

IOW, you screw the user -- they set a umask according to local policy or
need, but we ignore what *they* want, and instead set privs according to
what *SVN* wants. That is just backwards. Especially because there *isn't*
anything that "SVN wants". It is simply storing content.

Of course, if you start recording permissions, then you're going to end up
with a really messed up repository, as some people are open, and some are
closed. It will be a complete mish-mash of stuff.

The execute bit is the only interesting flag. Store that and we're set.


Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:44 2006

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