Maintain three branches of code: N, (N+1) and (N+2):

• Branch N corresponds to Prod version
• Branch (N+1) corresponds to QA version
• Branch (N+2) corresponds to DEV version

Access right to each branch needs to be separately given depending upon the team or person working on particular phase of implementation.

This task can be assigned to a Configuration Manager who will be responsible of providing & tracking access rights at any point of time.

Scenario#1: Production issue

If a person works on N version i.e. any Production issue, he will fix the issue on Nth version followed by merging of code in N+1 and N+2 version.

Thus, he would have access to all the three branches.

There would be two release packages: one for Prod environment and another for QA environment.

Scenario#2: QA defect

If a person works on (N+1) version i.e. any QA defect, he will fix the issue on (N+1)th version followed by merging of code in N+2 version only.

Thus, he would have access to (N+1) & (N+2) branches.

There would be only one release package i.e. for QA environment

Scenario#3: Development

Lastly, if person is involved only in new development, he will check in code only in (N+2)th version and thus have access only to (N+2) branch.

Collective Release package would be constructed only at the time of release for all the enhancements in scope of the release.

This way no changes would be lost and issues would not get reopened in future release.

Now, suppose there is a new release altogether, it means N version is obsolete & can be removed, N+1 will move to Prod, N+2 to QA and new branch i.e. N+3 will created for new enhancements.

Use of some good SVN tool like VSS or SVN can help in managing code versions at any point of time & also allow tagging & branching features.