Need repository layout references

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.

Do you mean you have multiple repositories for the code you describe above? — Sander Rijken, Dec 21 '10 at 19:21
I think what is meant is that there are 7 "applications" in a single repo. probably such as /trunk/project_1 , /trunk/project_2, ... — EnabrenTane, Dec 21 '10 at 19:31
that's what I read too. I was thinking making that /trunk/goober/project_x would mean you could commit at goober to catch all the changes related to a feature in the various projects at once. — jaydel, Dec 21 '10 at 19:35
@EnabrenTane: They're clearly not 7 distinct applications, since the question complains of an inability to do a single checkin for a single feature. — Phil Miller, Dec 21 '10 at 19:48
@Sander - yes, multiple repositories. Shocking, no? @EnabrenTane - no, all one application. — orbfish, Dec 21 '10 at 22:17

score 0 · Accepted Answer · edited May 23 '17 at 12:19

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

score -1 · Answer 2 · answered Dec 21 '10 at 19:34

-1

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.

answered Dec 21 '10 at 19:34

jaydel

14,389
14
62
98

That is my argument, but it was designed with 7 top level directories, and that's what I'm trying to change. My question is, how can I prove that this is bad bad bad? – orbfish Dec 21 '10 at 22:18

Need repository layout references

2 Answers2