Managing feature additions and bug fixes with Subversion
So, you’ve finished working on the initial release of an application and it goes live. At a later date you have to add an additional feature, sometimes more than one, but before these can go live, they require testing and approval.
Sometimes, the client wants subsequently implemented feature additions deployed before earlier ones. What happens if these involve changes to the same files?
In the meantime, bugs in the live application are identified and need fixing and deploying immediately, but these require changes to files that you’ve already changed for a feature addition, that is not ready to go live yet, and if it did, would break the application!
Sound familiar, if so, read on for a solution.
Essentially, the solution involves version control and branches, if you’re unfamiliar with these terms, check them out in google.
Process Summary
The solution described below involves keeping the live application code in the trunk of the repository, this is where live bug fixes are implemented, and code for each feature addition or release goes in a separate branch.
Details
As usual, when starting a new application, import the initial code into the trunk of the repository, then check out the trunk as your working copy on your development machine. Continue all pre-release development in the trunk.
When you start development on a new release stage of an application, create a branch by right clicking on the project root directory on you local working copy and in the TortoiseSVN sub menu, click “Branch/tag”.
Replace “trunk” in the “To URL” input box with “branches/<some release description>”, for example “phase1.1″, and check the “Switch working copy to new branch/tag” option, and click OK. You can continue adding feature additions to this branch by committing as usual.
To fix bugs in the live code base, do these in the trunk. Switch your working copy back to trunk by right-clicking on the root directory of the project in your working copy and select “Switch”.
Browse to the repository location you wish to switch to and click OK. Add the bug fixes and commit as usual.
To merge bug fixes back into the branch, switch to the branch.
Right click on the root directory of the project in your working copy and select “Merge” from the TortoiseSVN sub menu. Merge trunk revisions between when the last bug fix merge was applied to the branch (or the branch was created) and the HEAD revision of trunk (or some other revision).
This will create merged files in your working copy (which is currently the branch). Commit the merged files back to the repository. Continue adding additional features to the branch.
When the code in the branch is tested and approved for release, the process can be repeated to merge the branch code back into the trunk, by switching your working copy to trunk and merging changes made between the initial revision and the HEAD revision of the branch, into the trunk.
Multiple feature additions or releases = Multiple branches
In this case, you would create a branch (from the trunk) for each feature addition, or release, you need. This is because more than one feature addition may require modifications to the same file. If one feature addition is approved to go live, but another is not, and both feature additions required modification of the same file, putting the file live may cause problems.
Where you have multiple branches, the bug fixes made in trunk need to be merged into each of the “live” branches.
Furthermore, when a feature addition goes live and is merged into trunk, this must then be merged into all the other “live” branches.
When a feature release does go live, this branch is now “dead” and can be deleted.
(3 votes, average: 3.67 out of 5)
Loading ...
Leave a comment