>> Thanks for that. I haven't thought it all the way through, but if >> Unix ownership and permissions aren't granular enough and subversion's >> path-based authorization won't work, I will need to use ACLs. I think >> both subversion's path-based authorization and Unix >> ownership/permissions would be simpler to implement and maintain than >> ACLs so I'm hoping it doesn't come to that. >> > > ACLs really aren't as bad as they look at first. They work just like > permissions on Windows, which are one of the few things it does right. > My example is made much more difficult because /var/www contains > directories writable by other customers. > > I know *my* config.php files are chgrp apache and chmod 660, but I don't > expect everyone else to be so careful (and they shouldn't have to be). > > If you are going to go the version control route, I would suggest > setting up a new repository with only the code that he will be working > on. You can use a post-update script (or whatever svn calls them) on the > server to pull his code into production. He doesn't need to access the > files directly.
I think separate repositories would only be necessary when using distributed version control (git) as opposed to centralized (subversion). I think subversion's path-based authorization should eliminate the need for separate repositories? - Grant
