Proper SVN use of branches and trunk

I have a question as to the proper use of the trunk and branches for my SVN projects. For my team's project we create 3 major releases each year and sometimes a minor release or two in between. At any point in time we may have active development on 2 or even 3 releases. We have been doing all development in branches with a structure like:

/branches/project1/2009.01

/branches/project1/2009.06

/branches/project1/2009.09

/branches/project1/2009.10

To date whenever I get ready to create a branch for the next release I have merged the changes from the current branch to the trunk and then I create the new branch from the trunk. I then manually keep the latest dev branches up to date with bug-fixes to the previous release branches by merges through the trunk. No development or commits are ever performed on the trunk (except for the commit for the merges). Now I am wondering what I even need the trunk for at all. What would be wrong with just creating the next release branch directly from the previous release branch and merge bug fix updates directly from one b开发者_如何学Pythonranch to the next as well. Could I just delete the project under the trunk?

All the SVN best practices docs seem to indicate using the trunk for development but using separate branches for each release seems much easier to me since we can be working on 2 or 3 releases at one time. Is there any technical problem with my SVN usage? Suggestions?

Thanks!

I don't think there are any problems at all with the way you are working. If it works for you and your team then that's great. One advantage of keeping the trunk is that all of your branches come off the trunk, rather than ending up with a more messy situation where each new product branch hangs off the previous product branch. If you were to draw the revision graph you would see that it would get complex very quickly.

I agree with the_mandriill - there's nothing wrong with what you're doing, but there's also nothing wrong (IMO at least) of always questioning if you could do better.

There's a great article an cmcrossroads which will give you more than enough ideas about different ways of managing your code.

K

The way you're working is fine. At the moment, everything goes through trunk, so you've got a single point of reference to know where everything is. The problem with not using a trunk is having solid knowledge of where a bug has gone. With a trunk, the issue is a linear one. Without a trunk, it becomes exponential, as you have to compare every branch against every other branch to see what's in them.

Personally I'd rather not see any code originate in the release branches - make fixes in dev branches first, then merge through trunk to the release branch. Sometimes this isn't practical, but the merge history can always be fiddled to make it look like that's what happened. In general, a solid flow of code from dev branches, through trunk and into releases is quite understandable.

The reason for this is that you can then assign a trunk revision number to every fix, and trace that revision by simply examining each release's merge history against trunk. You can even tabulate this to see exactly what fixes have been released. (For example, see my answer here).

If a fix can originate in a release branch, this kind of comparisson becomes much harder. Still possible though I suppose. But if there's no trunk, you have to compare every release against each other and it becomes a much harder proposition.