Recommend good SVN layout for my project

Question

I've read the SVN red-bean book, and research how people layout their SVN repos, we're thinking of using SVN for our product, so would like suggestions on a repos layout.

The product is a desktop application, consisting of a number of .exe, graphics, etc. The current source layout is something like:

Program 1
Program 2
Program 3
Common Code
Graphics

It's important to note that sometimes Program 1 may use source files that are in Program 2 as well. Common Code and Graphics are used by all programs.

The main question is, if all our users are currently using version 2009 of the product, and we'll need to maintain it, release service packs etc, and begin development of version 2010 at the same time, should trunk contain changes for the 2009 release, or the 2010 release?

trunk (where 2010 development happens)
  Program 1
  Program 2
  Program 3
  Common Code
  Graphics  
branches
  v2009
    Program 1
    Program 2
    Program 3
    Common Code
    Graphics 
tags
  2009 (read only)
  2009 SP1 (read only)
  2009 SP2 (read only)

Would the above be the recommended layout? Or should the trunk contain 2009 development, and the 2010 development in some sort of testing branch?

The above layout does mean if a developer wish to work on Program 1, they'll still need to checkout the entire project, including Program 2, Program 3.

EDIT, more question

Thanks for the response to far. Got further question:

During development, there'll be 4 to 6 months where version 2009 is still being use by users and will need to be maintain, while 2010 development is going on. During that time, what's the best way to apply changes to both 2009 and 2010 release? Should those changes be done in the 2009 branch them port to 2010, or vice versa?

Answer 1

I like your layout. I think as the years go by, the trunk should always just be the current year's development. At the beginning of each new year you create a branch for the previous year's ongoing development and just name tags however you see fit.

Answer 2

Trunk always contains the most recent version, however it's not mandatory that you have to have only one trunk. A layout that I found useful is to have different dirs for every application, and then inside each of these, trunk/tags/branches. This way you have higher granularity in your versioning, at the cost of having to be more careful about the dependencies between codes.

Answer 3

For every project I've worked in that's been managed by Subversion, the trunk has held the "development" branch. Each release gets a tag (or branch, should it end up being maintained further). Any changes to the branches that are relevant to the devel branch are merged in as necessary.

Answer 4

If the main line of your development is in 2010, then trunk seems the right place for it. If you plan to merge from 2010 on trunk to 2009 in branches, then it also seems fine.

Assuming you use svn:externals for Common Code and Graphics, get into the habit of setting the external to a specific revision number, a little more work to start with, but less pain in the medium to long run.

Answer 5

You could also use the trunk as a reference for the current production release. All the development could be done in specific branches.

You then get an always accessible reference of the source code for operational maintenance.

Also, I suggest if you have stable Common Code across release to use svn:externals with the folowwing layout :

CommonCode:
  trunk
  branches
  tags

MyProduct
  trunk
    Dependencies -> CommonCode/trunk[rev. x]
  ...

You could also think about having a "release" branch for integration purposes.

Answer 6

Here's what's worked well for me. Development (new features, bug fixes) goes on in the trunk. When a major release is ready a release branch (v2009 for example) is created. Bugs found in the release branch get committed to the release branch first, merged to the trunk second, and merged to any other release branches last.

The point of the release branch is to have a stable place to apply bug fixes should you discover any bugs in released software. Release branches should always be available for cutting new releases.

So, bugs get fixed in whatever release branch they are found in first, and applied elsewhere second. This is based on the assumption that a customer discovered the bug and that it's of the utmost importance to satisfy that customer ASAP. If this is not the case, I would consider doing the fix in the branch that provided the most bang for the buck. Keep in mind that merges between branches are not always trivial. There can be major code changes that eliminate the bug, or require a hand merge.

Sometimes, when developing large features or redesigning large pieces of infrastructure, I'll create a development branch off of the trunk. Anything that gets merged to the trunk has to be merged up to the development branch. This makes the eventual merge back to the trunk much easier.

Answer 7

The simplest and most common way to do this is to have ongoing new development (2010) in your trunk and maintenance in a branch off of the trunk (2009). Once you release the trunk, branch it immediately (2010 branch) and work for the next version (2011) starts in the trunk.

In practice, it's usually not that simple. For instance, you might start working on 2011 before 2010 is even done. There are also a lot of more complicated situations that can arise. I would suggest the book Software Configuration Management Patterns as a good overview of different ways to manage branches.

As for where to patch things, I think you will find that other people will decide for you (management) but it is easiest to just make a policy that all bug fixes go in the release branch and then are merged to the trunk. This is because the bug fixes are likely to be relatively small compared to what is going on in the trunk.

By all means, once you decide on what scheme to use, document it and share the knowledge with everyone. In my experience a lot of people get easily confused about branching policies due to the flexibility of the tool, or inexperience. You do NOT want people to get confused about which branch to work in.

Answer 8

For what your doing your better off going with GIT, for each major release do a branch. This way if any bug comes up in a major release you can switch back to the branch and then cherry pic different commits in your GIT repository into your release branch.