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
Received on 2011-10-02 08:29:49 CEST