Question

I am anticipating a battle over Subversion repositories: currently we have a single web application that was checked in as 3 main projects and 2 reports projects (when I started 6 months ago), is now up to 7 projects, and is expected to grow further.

It is obvious to me that this is just not right, that a compiled executable cannot cross a version-control boundary if you want to make reasonable use of the version-control system. It's impossible to have a single checkin for a single feature, and that seems essential to me.

But I feel like I'm hand-waving when I try to explain this. Does anyone have any references, for Subversion or in general, that lays out this principle and has some authority behind it? I've done some searching and am just not coming up with what I need.

Was it helpful?

Solution

There are a lot of options in Subversion how to structure your repository. See the discussion of repository layout in the documentation.

I would normally follow these rules:

  • Is something a different project, no overlap, not the same users or groups? ==> You may use different repositories (but are not forced to.
  • Are there independent parts that will be tracked and built independent to each other? ==> Use the so called "multi-project-layout" (see below).
  • Do you develop a single application, and have there in different teams working, use the so called "single-project-layout".

The difference is the following:

  • Single project layout:

     Repo MyProject:
     trunk/
       java/
         src/
       ruby/
       doc/
       ...
     tags/
       rel1.0/
         java (references the copy of java of revision xxx)
         ruby (references the copy of ruby of revision xxx)
         ...
       rel1.1/
         ...
     branches/
       feature_x/
         java (references the copy of java of revision yyy)
         ...
    
  • Multi project layout:

     Repo MyProjectBundle:
     proj1/
       trunk/
         java/
           src/
       tags/
         rel1.0/
           java (references the copy of java of revision xxx)
           ...
         rel1.1/
           ...
       branches/
         feature_x/
           ...
     proj2/
       trunk/
       tags/
       branches/
     ...  
    

So the main differences are the following:

  • In multi project layout, it is pretty difficult to tag and branch over all projects, only one project is normally tagged there.
  • It a single project layout, you may branch and tag at will, and normally with the whole trunk. You may then change what you want to change, commit everything in one revision, and merge that back in one step.

As a reference, I only have the quoted SVN red book, and of course one of the many answers in stackoverflow: Subversion Repository Layout

OTHER TIPS

Since modules in svn only exist by convention, you can have a top level directory in your repository and put the various projects inside that and you can commit anywhere in the tree you want, including the top. So I wouldn't expect that you couldn't have a single checkin.

Your build system will be the part that partitions your application into it's various deliverables.

Cripes, I hope I've answered your question at least partially.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top