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

Re: svn commit: rev 3010 - trunk/notes

From: Justin Erenkrantz <jerenkrantz_at_apache.org>
Date: 2002-08-22 19:45:27 CEST

On Thu, Aug 22, 2002 at 12:33:00PM -0500, cmpilato@collab.net wrote:
> Who then provides the mapping between the SVN account name and OS
> account name? If a file in the repos is set to be only editable by
> bobjones, what do the OS perms look like?

The local client would - i.e. whomever is running the svn client
(i.e. bobjones).

So, if the SVN account bjones has read/write privs on file foo, but
no one else does, in Unix, it *might* look like this:

 rw------- bobjones users foo

(Owned by bobjones/users)

An unknown is what to do about the group permissions, but I think we
can figure out what to do about the user and the other (catch-all)
part.

I also tried to place a theoretical example in notes/permissions if
you want to see there as well.

> I understand completely. I'm just sensing that this particular
> solution to your problem is going to blossom into an unmaintainable
> mushroom cloud. :-)

Heh. Well, for my immediate purposes, I have a local patch which
suits me fine. Small, easy, quick patch - unfortunately, Win32's
permissions just aren't supported by APR (and may never be). I
should probably start collecting all my patches that will never
be accepted and post them somewhere (namely jlibtool support,
entry caching, svn:permissions, etc.).

> I am completely +1 on the Subversion *repository* having fine-grained
> access control, but that's where it ends for me. CVS ticked me off
> WAY too many times in the past by modifying my local disk perms,
> continually breaking CGI scripts and their datafiles and stuff. I
> don't want to end up there again.

Well, I'll say that CVS didn't let you control the permissions,
but if you knew what you were doing (i.e. tweak the ,v file), you
could get CVS to do the right permissions for you. However, we
should attempt to rethink this and ensure that your use case doesn't
blow us up. =)

And, as I've mentioned before, allow an escape hatch for the local
permissions set by the client. Either make it opt-in or opt-out
(don't care which). So, it can always have the current behavior -
APR_OS_DEFAULT.

But, I do think a lot of users might like having local files
read-only which are read-only in the repository (or are that way
via advisory locks). -- 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 19:46:04 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.