[PATCH] Repo layout

[C. Michael Pilato]

Ben Collins-Sussman wrote:

> Why is it easier to manage N separate lists of users, N separate lists
> of authorization rules, and N separate sets of hook scripts, rather
> than just managing 1 of each?   You say that this proposition isn't
> universally true, but don't say why.  I've never heard anyone argue
> the other direction.

In theory, the management of N repositories of one "project"[1] each 
versus one repository of N projects should lean heavily towards "the 
fewer the repositories, the easier."  But it doesn't always turn out to 
be so clear-cut.

In terms of configuration and hook scripts and such, it tends to boil 
down to namespace splitting -- either your configuration splits your 
projects into repositories and your hooks operate across the whole 
repository, or your configuration does no splitting and your hooks have 
to be taught about how to split the repository into logical projects. 
While mailer.py and Subversion authstuffs might be able to handle 
arbitrary splitting, there are many other hook scripts (even the simple 
"disallow empty log messages" shell code) that aren't so wise, and have 
to be tweaked to apply their policies to subsets of the repository 
instead of the whole thing.  Also, the claim that you have to maintain N 
sets of hooks is also largely false, because on supporting systems, each 
repository's hooks *can* be symlinks to (or thin wrappers around) a 
single set of real scripts.

In my opinion, where every project has the exact same needs in terms of 
configury and hook scripts, yeah, use a single repository.  But when 
this ideal uniform landscape isn't feasible, you're better off with 
multiple repositories.

[1] I'm using "project" to mean "logical grouping of versioned
     artifacts which can live in a distinct directory tree disjoint
     from other such groupings" -- please afford me much fuzz in
     that definition... you ultimately know what I mean.