trunk/ vs branches/ repo dirs

(I believe I've already read through all the book's sections on
this topic. Sorry for the long post.)

I'm trying to decide on layout for our repository. We're
migrating from CVS. The prescribed separation of "trunk/" vs
"branches/" top-level directories (TLDs) seems a bit arbitrary.
There is really not much special about trunk, so why should it
have its own TLD? It might not even be the most common
branch-off line for us. The only thing that makes it unique
AFAICT is that it's theoretically infinite, whereas other lines
should be finite. In our model, it doesn't seem to deserve its
own tree, relegating every other branch (~100 of them) to
branches/.

I expect all our users to be using the 'svn' CLI, and be able to
create branches at will. So 'switch'ing around a lot needs to be
as simple/clean/intuitive as possible. Thus the need for a
meaningful organization.

What makes more sense to us (at this point of naivety) is to have
the repo directory structure reflect the branch structure. IOW,
branches of trunk should be subdirectories of trunk, with depth
determined by branch-point. E.g., if 7.0 is a branch off of
trunk, then it's a subdirectory of trunk. And if 7.1 is a branch
off 7.0 then it's a subdirectory of 7.0. So you wind up with
something like this:

    trunk
    |-- 7.0
    | |-- 7.1
    | `-- teamA-hotfix
    |-- 8.0
    |-- teamA
    `-- teamB

An unfortunate consequence is that you would need to make sure
that each branch source tree is contained in a single directory,
say CONTENTS. Which would clutter the above to:

    trunk
    |-- CONTENTS
    |-- 7.0
    | |-- CONTENTS
    | |-- 7.1
    | | `-- CONTENTS
    | `-- teamA-hotfix
    | `-- CONTENTS
    |-- 8.0
    | `-- CONTENTS
    |-- teamA
    | `-- CONTENTS
    `-- teamB
        `-- CONTENTS

I'm probably going to have to employ a wrapper anyway (say
'svnw', so I should be able to hide the CONTENTS ugliness. Going
a step further, I might shorten trunk/ to t/ (and shorten
repo-root URLs to //, and add bash-completion) to make a typical
branch-switch-merge use case look like:

    # Make a hot-fix to the 7.1 branch, and merge to trunk.
    svnw copy //t/7.1 //t/7.1/teamA-hotfix
    svnw switch //t/7.1/teamA-hotfix
    svnw merge //t .
    svnw switch //t
    svnw merge //t/7.1/teamA-hotfix .

I like to do things in the "standard/book" way as much as
possible, but I'm worried about a single branches/ TLD causing a
chaos therein. Employing the subdir-by-branch scheme would force
the organization. (It seems that
svn.collab.net/repos/svn/branches is pretty well controlled, but
I wouldn't expect that in my group.)

If we go by the book and make trunk so special as to have its own
tree, then I suppose another organizational approach is to give
branches/ subdirectories like "bugfixes", "experimental",
"releases", "team-specific", etc; and then put the actual source
trees into the appropriate bucket.

Main questions (for anyone with the patience to have read this
far):

 1. Why is trunk so special? Any really good reasons to not
    do the subdir-by-branch scheme?

 2. Are you adding any categorization to your branches/ TLD?

 3. Are you using some other divergent scheme? Why did you
    choose it?

Thanks!

-- 
                          _ _     ___
                          |V|icah |- lliott
                          " "     """
mde_at_MicahElliott.com            <><             http://MicahElliott.com
PGP: 0x7C07CBF0          ICQ: 369060435      Linux/Ubuntu: 417195/12440
HackerKey: v4sw6YUPCJhw5ln5pr7OPck2ma9u8Lw3m5l6Ui2e7t3b8LDMOen6a3XsMRr5