Question

I am currently working on a project that has components in perl, .NET, C/C++, and Java. These components are inter-related, but are not tied to the same release schedule. Due to the very different build/testing environment requirements, lumping them all in to the same /bin /src /lib /etc /tests hierarchy is a bit unwieldy.

What are some good organizational hierarchies to use in source control when dealing with a project of this nature? I am currently leaning towards each language having its own branch:

repo/project1/perl/main/…

repo/project1/.NET/main/…

repo/project1/Java/main/…

How would your recommended hierarchy change if they DID have a tied release schedule?

Answer 1

I think what youve laid out is on the line. If you release the project as a whole with all components as opposed to releasing each component seperately then i might use svn:externals to differnt repo locations or entirely different repositories, then just associate the build via external with the latest compatible tagged release of a component.
Or if using git then use submodules to do much the same thing.

/repo/project1
  trunk/
    svn:external .Net /repo/project1/components/.Net
    svn:external perl /repo/project1/components/perl
    svn:external Java /repo/project1/components/Java
    -- other integration code or what have you --
  tags/
  branches/
  components/
    .Net/
      trunk/
      tags/
      branches/
    Java/
      trunk/
      tags/
      branches/
    perl/
      trunk/
      tags/
      branches/

The exact structure would depend on the workflow and exactly how the components are integrated but you get the idea.