Now we perform work in branches. These are merged down into trunk and killed when the features in them are done. So the trunk always contains the latest stable code.
When trunk is ready for a release a tag is created from trunk at that given point.
Now, how do we best handle the situation where we need to create a patch for a previous release?
We have a tag marking that release. But trunk now contains much more new features.
If we create a branch from the old tag how do we cleanly get the patch fixes into our trunk and also mark the new patch release with a new tag?
Can I tag the branch created from the initial release tag and reintegrate merge the branch with our trunk? Or will that pose a problem? I feel it might confuse Subversion.
This “picture” tries to illustrate the flow.
Work branches /-- itter. 1.0 --\ /- 2.0 -\ /------ 3.0 ----------\
/ \ / \ / / \
------------trunk----------------------------------------------------------------------
| | v2.0 tag / | v3.0 tag
| /
| V1.0 tag----------\ /
\-- Branch 1.1 --/
|
| V1.1 tag
Note that even though tags and branches are on the same lines here they actually reside in the standard trunk, branches, tags folder layout.
Note: the work branches does NOT have to have anything to do with a given release. I just named them 1.0 etc. But they could be named foo, bar or whatever.
We have now been using the approach of tagging releases from trunk and going back creating a branch from that tag if a patch is needed for a time and it has been working fine with both single and multiple teams.