[PATCH] Repo layout
sussman at red-bean.com
Tue Dec 20 13:11:24 CST 2005
On 12/20/05, C. Michael Pilato <cmpilato at red-bean.com> wrote:
> 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
> multiple repositories.
>  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