[Fedora] Re: Semi OT: Subversion

[Les Mikesell]

John Summerfield wrote:

>>>>
>>>>> Nobody should have the ability to update code owned by the next stage.
>>>>
>>>> That's not possible with most version control systems.  Everyone has 
>>>
>>> It's essential. You don't want everyone to be able to mess with 
>>> production code.
>>
>> I meant that no one ever changes anything that has ever been 
>> committed.  Everyone makes changes in their own workspace and a commit 
>> becomes a new revision.  Anyone can check out any revision that has 
>> ever been committed.  So, each stage checks out their own appropriate 
>> revision or tagged copy based on the workflow regardless of what else 
>> is happening in the repository.  It doesn't matter that someone can 
>> check in garbage, what matters is that the garbage revision not the 
>> one that QA tests/approves/tags to go to production.
> 
> How do you propose minimising the possibility of someone of ill intent 
> making unauthorised changes?

With revision control systems, you always have access to all versions 
and the ability to see the differences between them and who made the 
changes (most useful with text/source).  If something is important, I'd 
expect someone to review the changes as well as performing functional 
tests on any generated programs.

> Think what DoD, any big bank, Qantas, Westfield or any other significant 
> business would expect?

Don't they outsource everything these days?

>> You've got unix filesystem permissions and SELinux at your disposal to 
>> control direct repository access.  And the repository doesn't have to 
>> be on the same machine as any of the users.
> 
> Unix is weak. selinux is cumbersome.

Compared to?  How could you tell if something else is better?

>> If you don't trust your file access control, these don't matter much.
>>
> 
> Nobody should trust anything they're not forced to: that's what 
> Microsoft means when it talks of "trusted computing."

Why trust the people supplying something they happen to call "trusted"?

-- 
   Les Mikesell
    lesmikesell at gmail.com