[PATCH] Repo layout

[Ben Collins-Sussman]

Uncle.


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"[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.
>