svn - Structure of Projects in Version Control

Question

I know there are at least 10 different ways to structure project in version control. I'm curious what some methods being used are and which ones work for you. I've worked with SVN, TFS, and currently/unfortunately VSS. I've seen version control implemented very poorly and just OK, but never great.

Just to get the ball rolling, here is a review of things I've seen.

This example is SVN-based, but applies to most VCS's (not so much to distributed version control).

1. branch the individual projects that are part of site /division/web/projectName/vb/src/[trunk|branches|tags]

2. branch the whole site, in the case I've seen, the whole site except for core components was branched. /division/[trunk|branches|tags]/web/projectName/vb/src/

3. Use main-line a default, only branch when necessary for huge changes.

Answer 1

We practice highly componentised development using Java, we have about 250 modules in trunk that have independent life cycles. Dependencies are managed through Maven (that's a best practice right there), every iteration (bi-weekly) actively developed modules get tagged with a new version. 3 digit version numbers with strict semantics (major.minor.build - major changes means backwards incompatible, minor changes mean backwards compatible and build number changes mean backwards and forwards compatible). Our ultimate software product is an assembly that pulls in dozens of individual modules, again as Maven dependencies.

We branch modules/assemblies when we need to make a bug fix or enhancement for a released version and we can not deliver the HEAD version. Having tagged all versions makes this easy to do but branches still incur a significant administrative overhead (specifically keeping branches in sync with certain HEAD changesets) that are partly caused by our tools, Subversion is sub-optimal for managing branches.

We find that a fairly flat and above all predictable tree structure in the repository is crucial. It has allowed us to build release tools that take away a lot of the pain and danger from a manual release process (updated release notes, project compiles, unit tests run through, tag is made, no SNAPSHOT dependencies, etc). Avoid putting too much categorization or other logic in your tree structure.

We roughly do something like the following:

svnrepo/
  trunk/
    modules/
      m1/ --> will result in jar file
      m2/
      ...
    assemblies/
      a1/
      ...
  tags/
    modules/
      m1/
        1.0.0/
        1.0.1/
        1.1.0/
       m2/
      ...
    assemblies/
      a1/
        iteration-55/
        ...
  branches/
    m1/
      1.0/
      ...

For external dependencies, I can not overemphasize something like Maven: manage your dependencies as references to versioned, uniquely identified binary artifacts in a repository.

For intenal module/project structure: stick to a standard. Uniformity is key. Again, Maven can help here since it dictates a structure. Many structures are fine, as long as you stick to them.