Subversion branching and merging strategy

Branching strategy

Branch per Task (very good for maintenance [like Alabama MCS, Iowa MCS, Arkansas MCS, etc…])

Every development task is a new, independent branch. Tasks are merged into the permanent main branch as they are completed.

Branch per Component (very good for new development [like CMVS, Indiana CVIEW, etc…])

Each architectural component of the system is a new, independent branch. Components are merged into the main branch as they are completed.

When branch should be used and how

Trunk

The code in trunk is always maintained as close to release state as possible. Any developer making changes to the trunk must be absolutely certain that his or her part can be coded, tested and is ready to deploy within 1 day . If it takes more than 1 days, they are not allowed to directly change the code in the trunk. They have to create a branch.

Branch

Developer Branch

Each developer must create his or her own branch if their code will take more time to program than our normal deployment cycle (as described above in Trunk topic). It is the responsibility of the developer to regularly merge changes from trunk to his branch.

Feature branch

Create a feature branch if 2 or more developers are going to work on a new feature that will take considerable time to complete. It is the responsibility of the team lead to merge changes from trunk to this feature branch on a regular basis.

It is always beneficial to merge changes from trunk frequently (Once a day). Because, after a couple of days conflict between trunk version and branch version can get out of hand and merging will practically be impossible.

When the developer branch or feature branch is ready for release, merge changes back from the branch to trunk.

Process flow (Issue / Module lifecycle):

1. Developer will create a branch and start development.
2. When Unit test is finished, developer will inform QA with his machine URL for the functional testing.
3. QA will do functional testing.
4. Update from the trunk. Merge the code in Trunk.
5. QA will do full functional and regression testing for the issue.
6. If there is no error or issue, set the issue status to fixed and the version.
7. Is issue is fixable and test will be finished within a day and will resolve the problem without effecting any other issue? (SC – skip this point)
8. If yes, fix the issue and commit the solution directly to the trunk. (SC – skip this point)
9. If no, the merge will be reverted with proper precautions. (Process available in another document.)
10. Developer will take update and switch the branch workspace to the trunk.

Note: In trunk one issue should have only one commit version. (In most cases, point 8 is the exception to this rule.)

Below is the small flow chart I have created to explain the process.

Descriptions:

Trunk: is the main project stream from where the pre prod and prod versions will be built and released.

Branch: is the bifurcation of the project created to resolve some issue or task or enhancement or module.

Revision number: is the unique number given by the SVN for each committed code.

Build: This is the final version created to deploy in pre prod and prod.

Release: This is the future version of the application to be deployed (This will typically be reviewed with the customer).