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

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.