Separate Subversion branches per programming language?

Question

In some projects, I have to deal with more than one programming language (for example a Delphi GUI application which communicates with an C# or Java app). The Subversion repository currently contains three top branches, one per language.

Should I change this and group all parts of the project in the trunk like in the following example to make branching and tagging on project level easier?

project1
  branches
  ...
  tags
  ... 
  trunk
    csharp_app
    delphi_app
    java_app
    ...
project2
...

Answer 1

I don't think it's a good idea, because theoretically the different components could break compatibility, and if they don't stay synced up it would be hard to go back to the last working good config.

Answer 2

Programming language is irrelevant when you're managing a single project. A single module may be written in a variety of programming languages but still be too tightly coupled to worth separating. If each module of the application (whether or not it's written in the same language) is independent enough to be considered a separate project (and consequently, become independently versioned), you may want to separate it. Otherwise, don't do that.

Answer 3

Yes. The criterion is whether the apps require some form of synchronization of their features between each other, and that communication protocol (API, shared code, shared libs) may change over time. If the apps have nothing to do with each other, then separate repositories. Having apps written in multiple languages in the repository is irrelevant.

Answer 4

As these separate sub projects interact, then they need to move in lockstep, and you need to tag/branch/release the C#/Java/whatever components together. If they're unrelated then I would advocate (perhaps) separate repositories, or separate directories within the same repository. But not branches or tags.

Branches are used to manage different development streams on the same codebase. Tags are used to indicate a particular point in the project's evolution.

I think the programming language is irrelevant. Ask yourself what your releasable is, and how you need to manage this. I've done this successfully in the past with projects incorporating Java and C++, and the language is not the issue - it's keeping the components in sync that you need to manage.

I wouldn't necessarily create a new top-level directory per language. What happens if your Java component suddenly requires a JNI layer ? It strikes me that the implementation is reflected in the top-level directory structure, and that shouldn't really be a concern.