Beside SVN, how do you manage your development vs test vs production source code?

I'm working on a very large project with three phases of source code.

• Development source code: changes rapidly every second, and checked by our QA
• Test environment code: released to clients' QA department (released every 2-3 weeks)
• Production environment: after confirmed ok by client QA its released to prod. (every few months)

The system (governmental web app) is very large to track changes,bugs and hot fixes, sometimes the Testers could ask for a change, some other times the Production could ask for a hot fix or small update.

The problem is, when the Test or Production request changes, the development code is already changed a lot, and they always warn us they want only that small fix, do not upload anything new with it.

The ques开发者_如何学Pythontion, how should i manage the code for the 3 phases, and get back to Test or Production code any tie and fix that small one thing (reflecting the change to the current Development as well)?

Note: making a branch each time is too much, and i don't want the developers to be lost between updating the mainstream, the branch and the Test code!

Checkout from the particular revision that was supplied to Test or Production and merge changes later back to dev.

Instead of branching the trunk for every request (which would include new code not related to the quickchange or fix) what if you branch from your prod tag and made the change then test, qa and redeploy that.

Actually I think you should have your three branches * development (trunk) * QA * PROD

The merging is "quite easy" (as easy merging can be) as you always have to merge from QA to DEV and from PROD to DEV. This is quite a common setup which we use in many projects.

Edit: Normally you do not branch again on QA nor PROD.

Making a branch each time is too much, and i don't want the developers to be lost between updating the mainstream, the branch and the Test code!

Branching from the trunk for each and every patch is unnecessary (and it won't do what your test/prod teams need). However, you cannot entirely avoid branching, and you cannot avoid your staff having to work in multiple branches.

You should be able to keep the number of active branches down to (say) one for the version running in production, and one for the version that the testers are working on.