Is there anything wrong with this svn repo structure?

Question

I'm most familiar (and comfortable) with the 'standard' svn layout

+---trunk
|   +---file1
|   +---file2
|   \---...
+---tags
|   +---0.0.1
|   +---0.1.0
|   \---1.0.0
\---branches
    +---developer1
    |   +---file1
    |   +---file2
    |   \---...
    +---developer2
    \---developer3

My coworkers have a different background in version control systems, and would rather have this layout

+---trunk
|   \---branches
|       +---developer1
|       |   +---file1
|       |   +---file2
|       |   \---...
|       +---developer2
|       \---developer3
+---file1
+---file2
\---...

This just rubs me completely the wrong way, but I can't give sufficient technical reasons why we would run into problems with the second (current) approach.

I have a feeling that --mergeinfo wouldn't like this layout, but our server is running 1.4, and I'm not sure that an upgrade is likely anytime soon.

Answer 1

Wait, so if you check out trunk you will also get all your developers branches in the same folder? Is that right? Even if you only want the trunk, you have to grab all the branches at the same time? (a bit ill at the moment, hopefully I'm understanding properly)

That's horrible! On any decent sized project the checkout procedure suddenly got massively bloated in terms of bandwidth, storage and time.

That kills any benefits partial checkout (ie only checking out 1 folder and it's contents) of the repository has!

I heard of a games company that used SVN rather than GIT simply because their full repository was many GB in size and they needed partial checkouts so the staff could deal with it.

EDIT TO ADD:

Also, all tools you get for SVN will expect things to be in the layout you prefer. Sure, you may be able to configure them for your co-workers layout but why go thru that hassle?

Also, surely this means that if you want to create a new branch you can't do

svn cp .../trunk/ .../branches/mine

without doing

svn rm .../branches/mine/branches/<everyone elses>

afterwards, a bit clumsy no?

Answer 2

The main problem with the second layout is that you couldn't just checkout trunk without explicitly excluding the branches. Whereas with your (default) layout you can select to checkout either trunk or a development branch.

You won't run into technical problems with both.

Answer 3

The Subversion Book recommends your layout. However, this is only a recommendation as I understand it although some programs may (erroneously) require or assume it.

To Subversion, these are merely directories, and it does not matter how you name them or where you place them but you are probably correct that your coworkers' layout would be troublesome when it comes to merging as your branches would be below the trunk.

Answer 4

The decision should be based on the workings of the tool. SVN supports branches as different portions of the repo tree. In the second layout, what are the file1 and file2 that are peers to trunk? They don't seem to belong to a reasonable working tree.

The problem I have with the second layout is that files are in /trunk/branches/blah/blah. Are they on the trunk or on a branch? What does this mean?

You need to get very clear about what you mean by trunk and branch, and figure out what SVN structure will support those meanings.

As others have pointed out, you don't want to put branches inside trunk. To work well with svn, your structure should never nest the root of a working tree inside another working tree.

Answer 5

You are correct, and they are not. That's the standard structure, and it's the standard structure for a reason.

The main issue with theirs is that they are mixing different versions of the code in one directory. the trunk directory appears to have both files from the project, as well as the branches directory. This means that merging into or out of that directory will always be strange, and looking at the log for that directory will always intermingle changes in the branches and changes in the trunk.

The benefit of the standard layout is that each branch, tag, or trunk is a self-contained copy of the project, so merging between them will work, checking it out will give you the correct contents, etc.