How best to use SVN in this situation?

Looking for advice on how I should be using SVN within my product development.

At the moment I'm on version 2.2 of my product and have begun to use SVN with eclipse in order to keep track of my code. However I'm due to begin work on version 3 of the product which is essentially identical to 2.2 with a few big overhauls and some new features.

The problem is though 2.2 will still be under going bug fixing and a few minor features/tweaks with maybe 2-3 more releases before it becomes stationery and no more work is done on it - hopefully in time for version 3 release. So at the moment if my trunk is 2.2 with a stable tag at this point, where do I go from here? Keep in mind that i'd expect 3 to be branch from this tag in the trunk, but as 2.2 and 3 have similar classes 开发者_运维知识库if i make a minor change or bug fix i want it to relfect in version 3 rather than have to implement the bug fix twice, both in v2.2(trunk) and v3 branch.

Its also worth noting that my v3 branch may have branches on it for 'experimental' features that may not enter the first stable release of that particular product.

Any ideas on best practice for this situation would be greatly appreciated.

---

The basic approach would be to have a separate svn branch for each functional branch of development.

One instantiation of this would be to create a 2.x branch that will be where you do all of your development on the 2.2, 2.3, 2.4, ... series. This would be based off of wherever you are currently and you could use tags to denote each of the release points. You can also spawn off new branches for critical release fixes in the future, should they arise (e.g., 2.3.x). Then you could continue your primary development on trunk.

You'd of course use svn merge (as described at http://svnbook.red-bean.com/en/1.5/svn.branchmerge.html) to handle the merging between branches, should it be necessary. I strongly recommend using the latest version of Subversion (say, 1.5) as older versions required that you manually track the changes that had already been merged, whereas newer versions handle tracking that information for you.

To handle simple bug fixes that you want to merge down or up between branches, you could use cherry-picking to move just those changes between branches.

---

Consider this repository

    ROOT
    |-- trunk
    |-- tags
    |   `-- 2.2 => copy of branches/version_2
    `-- branches
        |-- version_2 => copy of trunk at 2.2
        |-- version_3_experimental => copy of trunk at 2.2
        `-- version_3 => copy of trunk at 2.2

You make every development for your version 3 in trunk, and any bug fix is done in the version_2 branch. If anything developed for version 2 should be in the version 3, you merge it in trunk. Afterward, you merge your trunk in branches/version_3. That way, your trunk keep growing according to the version 3.

When you have completed your version 2, create a tags from the version_2 branche.

Hope this helps.

---

You can use svn merge to merge branches of code.

---

Your development will look something like this:

                                              branch
                                              2.x -------------->
                                               |             |bring some more
                                               |  trunk 3.0  |changes if necessary
   trunk   --------------------------------------------------------------->
    2.2 stable        |      |      |        |  *     incorporated
       |              |      |      |        |  |Merge
   create branch     periodically bring      |  |branch 3 back
       |              | changes from trunk   |  |to trunk
       *              *      *      *        *  |
       branch------------------------------------X branch ends
         3                                            here

My suggestion is to delay creation of 2.x branch just before you merge 3.x to trunk. So that number of merges can be decreased.

Any changes from there on can be brought to trunk(3.x) but not the other way. This is typical approach when you phase out 2.x in favor of 3.x.