[PATCH] Repo layout
C. Michael Pilato
cmpilato at red-bean.com
Tue Dec 20 10:59:20 CST 2005
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" 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
 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.
More information about the svnbook-dev