Are nested trunk/branches/tags acceptable?

Question

In a recent embedded project, we have used the following svn structure:

project
    branches
    tags
    trunk
        electronics
        software
            branches
            tags
            trunk

As you can see, there is a nested branches/tags/trunk directory for the software part. This was quite practical for software devs as they could just work there without worrying about the rest.

However it doesn't look right to me, it could be confusing because of the multiple levels of branching, and people working higher in the hierarchy may be inconvenienced by all the garbage they have to download if they checkout the top trunk...

So I am thinking of going for a 1-trunk-only repository for the next project, and if developers don't want the non-software stuff, they can just checkout project/trunk/software and branch to project/branches/br-1234/software, etc.

What do you think about nested trunks? Pros&cons please!

As a side question: Should branches/tags always be copies of the trunk (or another branch), or is it acceptable to make a branch of a sub-directory of trunk?

Answer 1

I'd say definitely not ideal - gets very confusing very quickly. Given it doesn't actually take up much/any storage space to create branches/tags, there isn't much reason to end up with a structure like this. Branch at the project level only IMHO.

Answer 2

Acceptable to whom? There is no Pope of subversion, and every organization is free to do what fits it best. The versatility of SVN that gives you that freedom is a good thing.

Answer 3

Nested trunks indicate to me a collection of code with a different lifecycle than the parent code. I would consider these conceptually separate projects. Also, note that your repository can have multiple top-level projects, which should cut down on maintaining a separate repository for each project. I consider the use of separate repositories when I need separate repository-level configuration: accessibility, transport protocol, authentication/authorization (though these can be configured within a repository).

main_project
    branches
    tags
    trunk
        electronics
software
    branches
    tags
    trunk

Then you could either add a libs folder to main_project/trunk to contain a compiled form of software, or perhaps consider using an external SVN reference to point to software/trunk from within main_project/trunk.

Also "main_project" might now be better named "electronics", in which case you'd remove the extra "electrnoics" folder under "trunk".