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

Re: Breaking access-control in multiple files?

From: David Weintraub <qazwart_at_gmail.com>
Date: Wed, 12 Aug 2009 18:31:50 -0400

On Tue, Aug 11, 2009 at 11:52 PM, Adrian Shum <tcshum_at_taifook.com> wrote:

> I am using svn 1.5 with per-directory access control using WebDAV.
>
> my access-control file is growing huge because we have quite a lot
> modules in each repository, and becoming harder and harder to maintain.
>
> Is there any way that I can break the content of the file into multiple
> files
> (I even want content for access control of 1 repository break into files)?
>

A word of advice about the length of your access control list and your need
for per-directory access control: STOP DOING THAT!!!!

Let me explain. Just because you can do something doesn't make it wise.
Unless there are true intellectual properties issues at stake or there are
strict regulatory reasons, then there is really no reason to do such complex
access control.

Remember you have a revision control system, and your users are
professionals. They aught to know they shouldn't randomly change files
hither and thither. Since Subversion is a revision control system, you are
like an omnipotent being. You know all and nothing is hidden from you. A
developer can't simply change a file without you knowing. You can see this
in the logs, and being the all powerful being you are, can always revert
files back to their pristine state. Then you can pour out your wrath upon
the developer who messed up.

This is based upon 20+ years of experience as a SCM. I use to try to keep
everything in order and try to limit what users can do. However, I found
that I ended up doing more work, made developers upset because they couldn't
do their jobs, and causing more headaches. Developers would switch projects
which would mean I was always behind what was going on.

I do use access control. Here's what I do:

   - Some users have read access to the entire repository. Most others have
   write access. Non-development staff have no access at all.
   - I have the "tags" directories as add-only. Developers can add tags, but
   they can't edit any file in the tags directory. You need to do this with a
   pre-commit hook.
   - I lock recently released branches to prevent developers from
   accidentally committing new code to them. Obsolete branches are deleted.
   (Remember, I can still get the history from deleted branches and put them
   back if necessary)
   - Sometimes, a project manager will say "These users and only these users
   should have access to this release branch. I don't encourage this, but
   sometimes when a release is eminent, the project manager doesn't want
   everyone making "minor" changes.

And that's about it. I use a pre-commit hook to control commits, so I don't
really depend upon WebDAV except for stating initial read/write access to
the entire repository. We use LDAP connected to our Windows active
directory. That way, your Windows password is your Subversion password, and
if you have an email account, and are in the Subversion group, you have
access to the repository.

If you're using svnseve, the authz file has to be a single file. I don't
know if you can have multiple authz files if you're using Apache. However,
remember the more complex your permisisoning structure, the more work your
Subversion server must to do serve files, the more maintenance you have to
do in order to maintaint it, and the more frustrated your users wil be
because something isn't setup correctly, and they've lost a few hours of
work because they couldn't do something.

-- 
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2383059
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-13 00:32:51 CEST

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

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