R – Best setup for code promotion and feature branching in Subversion

svnvb6version controlvisual studio

We're a 4-person team and haven't been far from our comfort zone in several years, but we're growing and would like to catch up to the times. I have been tasked with finding the best way to implement Continuous Integration (automated builds, branching for code maintenance and new features, etc). We are looking at switching from SourceSafe 2005 to Subversion to handle our version control. From what I've read, Subversion is a much better choice for doing code promotion, branches, and merging between branches. We will probably use the following products:

  • VisualSVN Server
  • TortoiseSVN (for integration with Windows Explorer)
  • VisualSVN (for integration with Visual Studio 2005)
  • SVNVB6 (for integration with Visual Basic 6)
  • FinalBuilder

What is the best way to organize the repository for code promotion and feature branching? Here is an example of our current SourceSafe structure:

  • root
    • Visual Studio 2005 projects
      • ProjectName
        • Solution file, project files, and code files here
        • \bin
          • \Release
            • Compiled release binaries here
    • Visual Basic 6 projects
      • ProjectName
        • Project files and code files here
        • Compiled binaries (.dll, .exe, .ocx) here
    • Documentation
      • Documentation files here

Should we structure like this?

  • root
    • branches (each branched from trunk)
      • Development.FeatureA
      • Development.FeatureB
      • Test (Built nightly with FinalBuilder ???)
      • Production (Built nightly with FinalBuilder ???)
      • Production.BugFixA (Reverse Integrate to Production branch, Test branch, and trunk ???)
    • tags
      • Development.v1 (tagged after each successful build)
      • Development.v2
      • Development.v3
      • Test.v1
      • Test.v2
      • Test.v3
      • Production.v1
      • Production.v2
      • Production.v3
    • trunk (Development code – Built nightly with FinalBuilder)
      • Visual Studion 2005 projects
        • ProjectName
          • Solution file here
          • ProjectName
            • Project files and code files here
      • Visual Basic 6 projects
        • ProjectName
          • Project files and code files here

Since a large part of our software is still COM (VB6) and needs to be registered (using regsvr32), should the binaries be version-controlled? How should we handle registering/unregistering the components when we need to work on the different branches (possibly with different COM compatibility)?

Are we way off the mark?

Best Answer

First off, don't use a top level trunk branches tags, use a per project trunk branches tags like this:

/Projects
  /CashCowProject
    /branches
    /tags
    /trunk
      /vs
      /doc

This means that tracker tools can look at http://svn/Projects/CashCowProject and see ALL activity on that project, and not get any activity on any other project. Also it forces you to control references between projects, meaning that your top-level projects won't change without an entry in trunk.

When projects reference each other, use svn:externals to pull in a tag from the library project you need. Use vendor branches as described in the red-bean book to handle 3rd party libraries, even binaries.

Keeping library binaries in SVN is ok. Might want to consider a separate repository for this, although we don't.

For code promotion, keep a stable branch for a particular version and only ever merge from trunk into that branch, then tag from that branch. This will give you an auditable record of what's in each release.

You can keep COM binaries in there if you're not going to pull in the source and build it. You can write a post-upgrade script for tortoise which will go around registering any COM objects it finds.

Related Topic