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

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 2

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.