Is trunk needed in multiversion projects

Question

I work in a project with one released version in maintenance and two or more versions in development simultaneously.

Here is where the doubts about the need of trunk arises.

I've read the SVN Book in The Read Bean and others (Pragmatic Version Control with Subversion) and all of then suggest using a trunk-centric mode of development. I don't know if in my case this is applicable and if exist other projects with multiversion release cycle that use other schemas successfully.

Why is the trunk-centric mode the recommended? Is there any problem with the version branches going more and more far of the trunk? I this schema the integrations with trunk have any sense?

                                          /-----gamma-----/(3)---------->
                                         /               /
               /----beta---/(1)---/(2)--/---beta--------/--\
              /           /      /                          \
     /------------alpha--/------/---\                        \
    /                                \                        \
------------trunk--------------------(a)----------------------(b)------------------>

Edit:

When I say two or more development versions I mean versions of the software with incremental level of functionality. In the graphic above:

• alpha: functionality A.
• beta: functionality A + B.
• gamma: functionality A + B + C.

Meaning that all the functionality of a branch is included in later branches (through sync merges). The branches differ in stability level (older branches are more stable) and in functionality (young branches have new functionality).

Edit 2, after TridenT answer:

The development of the stable version is done in a trunk's branch and then merged back to trunk when is stable, so the trunk contains all the stable changes and in the end the more stable version of the software.

I'm asking this question now because I'm rethinking the branching strategy of the whole project.

Answer 1

I'm going to take your chart and reorganize it a bit:

                                          /-----gamma-----/(3)---------->
                                         /               /
               /----beta---/(1)---/(2)--/---beta--------/--\
              /           /      /                          \
     /------------alpha--/------/---\                        \
    /                                \                        \
------------trunk--------------------(a)----------------------(b)------------------>

First, remove trunk, since you're not using it. Yes, you're merging back into the trunk, but you never take code out of it. Instead, beta comes from alpha and gamma comes from beta. Might as well save yourself all that effort merging back into a code line you never really use:

                                          /-----gamma-----/(3)---------->
                                         /               /
               /----beta---/(1)---/(2)--/---beta--------/
              /           /      /                      
     /------------alpha--/------/                    
    /                                      
trunk

Now, let's straighten out your chart, so that the main development line is nice and straight:

trunk-alpha-------beta-----------------------gamma-------------------------->
            \           /      /       \                /
             \---alpha-/------/         \---beta-------/

And, finally flip over everything...

             /-alpha-\-----\            /--beta-------\
            /         \     \          /               \
trunk------/--(beta)---\-----\--------/-(gamma)---------\------(gamma)-------->

There's your trunk!

I know what you're doing. You're not coding on trunk because trunk is suppose to represent your release. In your original diagram, there are two versions on trunk. Point (a) where you merge branch alpha back to trunk, and Point (b) where you merge branch beta back to trunk. This represents your Release alpha and Release beta.

However, that's what tags are for! You make a tag on a release, and your tag now represents your release. And, it's better because a tag preserves the history of your file.

Let's say you go to your trunk at Point (b) and take a log of a particular file. You see the file at Point (b) and you see another version at Point (a). But, you have no idea how that file was changed between point (a) and point (b). In fact, you don't even know who's release responsible for a particular change.

However, if you did a tag off the branch instead of merging your code back to trunk, you'd see the entire history of that file all the back to the very first version of the file. Subversion's log command (if you don't use the --stop-on-copy switch) will take you from the tag down to branch beta and back to trunk.

Ah, you say, but how can I see the differences between release alpha and release beta? In my scheme, I can look at the history of the trunk!

However, if you need to see all the changes between one release and another, you could easily just do a diff between two tags. And, sine they're tags, it's much easier to find the actual release version instead of trying to figure out which version on trunk represents your which release.

So, you do have a trunk, but you just don't call it that.