Typically most teams that use subversion have developers working off of the trunk and checking in changes/bugs to the trunk. Once developers check in changes to the trunk and the build succeeds, a separate Test team can simultaneously test the checked in code/features while developers are working on other features. When all features have been checked in to the trunk and successfully tested, the code can be released and a snapshot of the Project/Release is placed in the 'tags' directory.
But it doesn't always happen that developers check-in and checkout from the trunk alone. Here are some other possible scenarios :
1. What do I do if I am working on a feature that might take couple of weeks to finish ?
If you are working on a feature that might take a couple of weeks to finish, then checking in code at the end of the day or at frequent intervals without completing the feature will break the build which will in turn affect the Test team and the other developers. But if you don't check in the code for a couple of weeks then the trunk might drift too far apart resulting in large number of merge conflicts when you finally decide to check in the code.
In this case you should create a feature branch for that particular feature. Here is how:
a. Update the trunk and make sure it is on the latest revision from where you want to branch out.
b. Create a separate branch from the trunk (also called a feature branch) where you will be checking in changes related to your feature.
(Click to Enlarge)
The 'FROM URL' should point to the Trunk in the svn repository and the 'TO URL' should be the Url of your feature branch. If a branch with the name does not already exist in the SVN repository, then a branch is created with the contents from the Trunk.
c. Once the feature branch is created, you can create a local repository and check out the files from the new branch or you can switch the trunk to point to the new feature branch. (I usually just create a new local repository).
You can now check in changes to this feature branch regularly without breaking the trunk build. But it is possible that during the time you are working on your feature, other developers may check in bug fixes/other code to trunk that you need to pull in to your feature branch. This way the feature branch catches up with the latest changes in the trunk and merging the branch back to the trunk will not be a pain. So maybe once every day the developer needs to pull in the changes from the trunk to the feature branch. Here is how:
a. Update your branch. (Right click on the root level of the branch + SVN Update)
b. Right click on the branch where you need to merge to and select Merge. Make sure to merge at the root level of the feature branch. This is because if you merge at the file level then SVN will maintain a svn:mergeinfo property for that file in addition to maintaining the svn:mergeinfo property for the parent directory. So everytime you merge, the svn:mergeinfo property will get updated at the file level and directory level. To avoid this always merge at the root level of the branch.
c. Then select "Merge a range of Revisions".
(Click to enlarge)
d. Select the Trunk as the 'From URL'. There is no need to provide any revision range. So just leave that blank.
(Click to enlarge)
e. Finally do a Test Merge before running the real Merge. This will show you any conflicts that may occur without actually merging the code.
Then do a real merge to merge all the latest changes from the trunk to your branch. Now you have caught up with the trunk and can continue working being sure that you are working off the latest code.
SVN 1.5 and later automatically keeps track of what has been merged with the previous merge. So the next time you merge from the trunk to the branch it will only merge those revisions that have not already been merged. For example if the first time, revisions 1-10 were merged, then the second time you merge revisions 11-20 will be merged without merging previously merged revisions. SVN does this by maintaining a property called svn:mergeinfo on each directory/file that it merges. So don't modify/delete this property else SVN will lose track of what has already been merged.
Note: If you get tree conflict when merging then make sure you are merging the correct directory levels from trunk to branch. E.g Make sure you are merging the top level of the trunk with the top level of the branch.
Now a week passes by and you have finished your feature. Its time to reintegrate the branch back to the trunk. Since your branch is almost similar to the trunk (assuming you have merged on a regular basis), reintegrating the branch will not be very hard. Here is how you reintegrate the branch :
a. Check in all your feature branch changes. Update your trunk & branch.
b. Make sure to do one last merge from trunk to branch as described above. This needs to be done before reintegrating a branch to make sure all trunk changes have been merged to branch.
c. Right click on the trunk where you need to merge to and select Merge.
d. Select "Reintegrate a branch"
(Click to enlarge)
e. Select your feature branch in the 'From URL'.
(Click to enlarge)
f. Run a Test Merge before reintegrating the branch to the Trunk. If any conflicts arise when merging then resolve the conflicts.
Finally !!! Reintegrated your branch to the trunk.
Note: Always merge in one direction. E.g. If you are merging continuously from trunk to feature branch using the "Merge a range of Revisions" option and then merge from feature branch back to trunk using the "Merge a range of Revisions" option (instead of the "Reintegrate a branch") then you might get a "Tree conflict". This is because the trunk does not have any information on the merges that were done from trunk to the feature branch (only feature branch has this info) and thinks that there are duplicate files.
"I need to work on some features for a particular e-fix. I can create a efix branch and work on that branch. But I don't want to regularly merge from the trunk because there are other developers checking in code/features to the main trunk that will not be included in the efix. But I do want to check in any changes to the exif branch to the main trunk as well because the features in the efix will also be included with the next major release (trunk). Now what ?_
In this case you would do the similar thing that you did previously. Just that instead of merging often from the Trunk to the branch, you would merge from the efix branch to the the trunk as long as the merge does not break the trunk. Here is how:
a. Create a separate branch from the trunk (an efix branch) where you will be checking in any efix related changes. (Same as you did previously)
The 'FROM URL' should point to the Trunk in the svn repository and the 'TO URL' should be the Url of your efix branch. If a branch with the name does not already exist in the SVN repository, then a branch is created with the contents from the Trunk.
b. Once the efix branch is created, you can create a local repository and check out the files from the new branch.
c. Check in your efix branch code once you are done with a feature/fix. Before moving on to the next feature, update your trunk and efix branch.
d. Right click on the trunk where you want to merge the changes to -> Select Merge.
e. Then select "Merge a range of Revisions".
f. Select the efix branch as the 'From URL'. There is no need to provide any revision range. So just leave that blank.
g. Finally do a Test Merge before running the real Merge.
All changes from your efix branch will be merged to the trunk.
Here is a high level explanation of how the merge works when you have a feature branch and efix branch at the same time:
(Click to enlarge)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.