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

Re: access control in Subversion

From: Dimitri Papadopoulos-Orfanos <papadopo_at_shfj.cea.fr>
Date: 2004-03-16 17:12:42 CET


> seems that your company's policies have painted you in a bit of a corner. the
> authorization authz module for apache will do exactly this. i don't have any
> idea what you have in mind for "write only" users though. blindfolds?

We actually don't have "write only" users. An additional rule was
probably missing: Files that can be written by a group/person can also
be read by the same group/person.

As for Apache, apart from the administrative hassle it would mean for
me, I wish to depend on as few external packages as possible, because
that increases the possibility something goes wrong during OS upgrades
(Subversion already relies on BD, I'd rather not add Apache). Also does
Apache allow to read a file without authentication and require
authentication for writing it?

> it sounds to me like it may be a lot easier to get your dark overlords to
> authorize the purchase of a commercial sccm. then again, they seem to not be
> bothered by keeping you from getting any work done.

We already have Perforce. However purchasing and upgrading licenses is
hell: my organisation usually deal with local resellers but Perforce
have no local resellers. For the lack of a local reseller everything
that can go wrong will go wrong when upgrading licenses (and that's
probably not Perforce's fault). I just want to avoid that and was
therefore thinking of moving to Subversion.

Otherwise I have to agree there are many constraints here - but I can't
address and change them all. On the other hand, facilitating my own work
is not the unique goal of my organisation. There are other issues to
take into account, such as security issues that may be addressed by
organisation-wide policies. Organisation-wide policies tend to get in
the way of part of the people in an organisation; some policies are
better, some of them are more flexible, and some of them harm lots of
people in the organisation.


Dimitri Papadopoulos
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 16 17:13:15 2004

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.