[Fedora] Re: Semi OT: Subversion

[John Summerfield]

Les Mikesell wrote:
> Ashley M. Kirchner wrote:
>> Les Mikesell wrote:
>>> What you really want is to have everyone who makes changes use their 
>>> own working copy (and perhaps their own test server to view it).
>>    At the moment, that's kinda what's setup.  They have their own 
>> local copy that they work on.  When they're ready, they check in their 
>> new code to our test server which we then look at and see what works 
>> and doesn't.  And only when we approve it, it gets pushed to the live 
>> server.  They just need to be able to hit that test server and look at 
>> the changes they made as if they're just browsing the actual site 
>> (through a browser) so we can all get a feel for what the live site 
>> will also look like or behave.
> 
> The best approach here is to set up virtual servers for views of the 
> development working copies.  Depending on the web server, you may need 
> to run these on different ports so several can co-exist on the same 
> machine.  This lets development run at its own pace ahead of QA and 
> different people can be working on different changes at the same time.



I'm pretty much with Les, but ...
1. A development site that people play with.
2. A test site that is what development proposes QA should have.
3. A QA site, maintained by the QA folk taking releases from testing, 
fully as if it were the production site.
4. The production site.

Individuals may have their own sandpit. Always, the next stage updates 
from the previous stage's master repo.

Nobody should have the ability to update code owned by the next stage.

Sometimes, the production site will need to have unscheduled 
maintenance. Probably, folk at level 1 will generate emergency fixes 
against their version of what's in production, and someone in 
production, with the necessary authority, will take the fix and apply it.

It still needs to go through stages 2 & 3 ASAP. Emergency fixes are 
always a risk, and should only be used when the risk of using them is 
less than the risk of not.


This is substantially the process we followed in the 80s, it's not new 
(and there may be refinements), in an organisation of national 
significance. We used panvalet for source code management, panexec to 
manage executables, and ACF/II to control access.

The tools aren't that important, the procedures and facilities are.


<moan> If E*Trade followed this sort of procedure, its website would 
work</moan>



-- 

Cheers
John

-- spambait
1aaaaaaa at coco.merseine.nu  Z1aaaaaaa at coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

Please do not reply off-list