subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Chapman <dcchap...@acm.org>
Subject Re: File access control
Date Sun, 02 Oct 2011 03:58:33 GMT
On 10/1/2011 8:26 PM, 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? I
>>> suppose each developer would require a separate staging machine to work this
>>> way.
>> If a developer has access to only part of the Web site, he/she will be able
>> to test only part of the Web site.  That is not scalable in the long run.
>>   As soon as one part of the Web site relies on another for functioning, your
>> development methodology will break.
> Your post has given me a lot to think about, but I don't agree that
> one part of the website relying on another part means the development
> methodology will break.  Whenever something needs to be worked on, I
> would give the developer access to all necessary files.  If it turns
> out I didn't grant access to enough files, I can always add one or
> more files to the accessible list.  Can you give me an example of a
> situation that would break my proposed development methodology?
>

Easy:  you go out to lunch right before your developer finds he/she 
needs a file.  Now you're paying for someone to sit and wait for you to 
come back from lunch.  Any time you are not immediately available to 
change the permissions, you are losing money.

"Not scalable" means that the management burden will grow tremendously 
as the amount of code in your Web site grows.  You may be willing to 
adjust the permissions list regularly if there are only 100 files, but 
what if there are 1,000?  Or 10,000?  What if there are 20 developers?  
Or 50?  What if some of them are in Europe, or India?  For every 
project, for every developer, you are going to have to build a list of 
files to access, and that list is likely to need tuning as the project 
proceeds.

Limits on source code access are very common; for example, a developer 
working on analysis software doesn't need to see the internals of the 
GUI (and vice versa).  Usually the source code for different products is 
in different directories, making access control manageable.  It requires 
some work to partition code, but the way of thinking it induces is good 
for Software Engineering (as opposed to hacking something together).

I'm not a commercial Web site developer, but I would expect that any 
feature which involves a fair amount of computation is going to require 
quite a bit of code.  You're going to want to isolate that code (with 
APIs etc.) for testability anyway; why not move it into a separate 
directory?

Look back at the statement you made above:  you are willing to make 
testing more difficult in order to protect your source code.  If testing 
is harder, less will be done - it's human nature.  That could easily 
degrade the quality of the product to be delivered.  Most companies 
accept the theft risk (using the legal system as a hammer) in order to 
get a higher quality product.  That's why you're finding so little 
support for your methodology in the tools.

-- 
     David Chapman         dcchapman@acm.org
     Chapman Consulting -- San Jose, CA


Mime
View raw message