Re: File access control
From: Ryan Schmidt <subversion-2011a_at_ryandesign.com>
Date: Sat, 1 Oct 2011 20:51:03 -0500
On Oct 1, 2011, at 20:07, Grant wrote:
>> There is a repository -- a database -- that holds your code. The current version and all past versions, including, if you like, branches. This could be on any server you like -- the production server, the development server, a completely separate server -- doesn't really matter. That server will run some kind of Subversion server software -- svnserve perhaps, or Apache 2 with mod_dav_svn.
You're right, your restriction of not wanting to give the developer access to all the files needed to make the web site function does complicate matters. It's a situation I didn't have to deal with in the web development shop where I worked. We didn't use authz; everyone had access to everything.
Usually, you want to test your work before you commit it. But in your case you might adopt a different policy, of allowing people to commit work, in order to then test it on a central development server. The development server could have a full working copy of the site, and could be configured with a post-commit hook to automatically update itself after every commit:
http://subversion.apache.org/faq.html#website-auto-update
Nobody would have permission to modify that working copy in any way; only the server itself would have the ability to update it, by running "svn update". This ensures it's a pristine copy of what's in the repository.
You could grant your untrusted developers access to relevant parts of the repository using authz, which they would check out to their local machines, modify, commit, and then access your dev server's central URL to see if their changes worked. If not, they'd make another change and commit, until things worked.
Instead of having this developer modify the trunk, you might give them access to a special branch of the code. This way their changes are isolated from your trusted developers, or even from other untrusted developers. Somebody trusted then takes on the task of merging their work into the trunk when it's done.
In this scenario, you might indeed set up a separate virtual host (separate instance of the app, separate dev server working copy) for each such branch. No need for there to be separate servers though.
|
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.