[Fedora] Re: Semi OT: Subversion

[Les Mikesell]

John Summerfield wrote:

>> 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.

I'd say individuals _must_ have their own working copy.  There are 
different schools of thought on how development should be committed to 
the repository, though.  Some like to make branches for every change and 
  merge them to the trunk after they are complete.  Personally I think 
that is too much work and like to have all new development on the trunk 
where everyone can easily update to pick up the changes others have 
made.   The QA workspace is then periodically updated to pick up the new 
work, and when everything is good, makes a tag or branch for the release 
and production is updated to that state.

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

That's not possible with most version control systems.  Everyone has 
their own workspace, including QA/testing, and they get the revision 
they ask for, regardless of what else is happening in the repository. 
Generally you just want to pass tags or revision numbers around to 
indicate what is ready for 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.

You should always have release branches/tags so at any point you can 
either revert to an exact copy of a prior release or pull an exact copy 
of the version you need to fix into a workspace to fix 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.

You still want this committed to a branch so you'll be able to repeat 
the procedure.


-- 
   Les Mikesell
    lesmikesell at gmail.com