On Sat, 01 Oct 2011 18:07:29 +0000, Grant wrote: ... > Ouch. If testing is done on the developer's local machine, he will > need a full working copy and it will be impossible to restrict read > access to one or a few files as I had planned to do with path-based > authz. Instead, could I check out a working copy of the repository to > a staging machine of mine and allow the developer to check out only > one or a few files as defined via path-based authz, thereby requiring > him to commit his changes and update the staging machine's working > copy in order to test his changes and debug?
First of all, either he would need permission to do the 'svn up' on the staging machine, which, unless you do some sudo magic, would give him access to all the code, or you need to set things up so the staging area do update itself automatically on every commit made. Both is possible. But: In essence this setup means that I, the developer, have to commit every time I want to test something. Sometimes, that would mean three times a minute. This is a major nuisance for the devs, and it also means that the history accumulated is pretty much worthless, both because nobody will do meaningful commit messages and because there are no meaningful commits. > I suppose each developer > would require a separate staging machine to work this way. In addition it means that you *need* a branch for every dev's work, because otherwise you are basically back to 'everyone edits the master copy', and that you are the only one who can do merges anyway. > I'm really getting the square peg round hole feeling. The workflow > you describe is elegant and very enticing but it gives all of my code > away. The prevailing attitude seems to be that developers should be > trusted, If you don't trust me not to run away with the code, why should I trust you to pay me at the end of the month/contract? > but this goes against everything I've learned about system > administration where security is taken seriously and trust doesn't cut Well, if I was serious about getting at your code I would try to hack your production web server, or to get into an admin position at your company. Or cleaning personnel. :-) If you don't actually not want devs to *see* other code then you should instead aim on physical security. No external drives on the machines, no internet or something SElinuxy to prevent copies out of the secured part into the mailer or such. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds@*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800
