[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Fedora] Re: Semi OT: Subversion

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 gmail com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]