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

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 "electronics" folder under "trunk".

Answer 2

The short answer to all your questions: no.

I'm envisioning an Abbott & Costello "who's on first" discussion: "I merged it to the trunk" "Which trunk?" "the trunk of the integration branch" "So the trunk is up to date?" "Which trunk?"

New team members will have a hard time adapting to a scheme that contradicts their prior experience. They'll have to search for internal documentation or ask questions about something that should be really simple.

Many tools & IDEs are way more onerous to work with if a non-standard layout is used.

Of more concern is your second question about branching/tagging subsets of the trunk or a branch. with subversions cheap copies there is no gain on space or time to branch/tag a subset - and more importantly your svn:mergeinfo will become way less useful if people branch/tag anywhere but top level.

Answer 3

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.