views:

195

answers:

2

We are running a large project with several different languages: Java, Python, PHP, SQL and Perl.

Until now people have been working in their own private repositories, but now we want to merge the entire project in a single repository. The question now is: how should the directory structure look? Should we have separate directories for each language, or should we separate it by component/project? How well does python/perl/java cope with a common directory layout?

+4  A: 

My experience indicates that this kind of layout is best:

mylib/
    src/
       java/
       python/
       perl/
       .../
    bin/
       java/
       python/
       perl/
    stage/
    dist/

src is your source, and is the only thing checked in.

bin is where "compilation" occurs to during the build, and is not checked in.

stage is where you copy things during the build to prepare them for packaging

dist is where you put the build artifacts

I put the module/component/library at the top of the hierarchy, because I build every module separately, and use a dependency manager to combine them as needed.

Of course, naming conventions vary. But I've found this to work quite satisfactorily.

Jared
In this source layout, is the module level above or below the src/ level? I.e. mylib/src/java or /src/java/mylib?
Joakim Lundborg
I keep all of my modules separate, because I build them separately and use a dependency manager to combine them. For that reason, I would do mylib/src/java.
Jared
Edited to reflect lib question.
Jared
+1  A: 

I think the best thing to do would be to ensure that your various modules don't depend upon being in the same directory (i.e. separate by component). A lot of people seem to be deathly afraid of this idea, but a good set of build scripts should be able to automate away any pain.

The end goal would be to make it easy to install the infrastructure, and then really easy to work on a single component once the environment is setup.

(It's important to note that I come from the Perl and CL worlds, where we install "modules" into some global location, like ~/perl or ~/.sbcl, rather than including each module with each project, like Java people do. You'd think this would be a maintenance problem, but it ends up not being one. With a script that updates each module from your git repository (or CPAN) on a regular basis, it is really the best way.)

Edit: one more thing:

Projects always have external dependencies. My projects need Postgres and a working Linux install. It would be insane to bundle this with the app code in version control -- but a script to get everything setup on a fresh workstation is very helpful.

I guess what I'm trying to say, in a roundabout way perhaps, is that I don't think you should treat your internal modules differently from external modules.

jrockway