Layered repositories

[Matt Mackall]

On Fri, Sep 16, 2005 at 08:40:28PM +0200, Erich Schubert wrote:
> Hi,
> Up to now I've been using subversion for my experiments, now I wonder if
> maybe mercurial would be an interesting base to build upon... Right now
> I have avoided looking at all the new SCMs out there - there are just
> way to many of them - and especially the 'distributed' approach has
> nothing to offer for me, I think.

Actually what you describe below sounds like a pretty good match for
Mercurial's distributed model. This is in fact what it's used for:
maintaining many independent lines of development from a similar base.

Put all of the "generic bits" in a "central" repository. Put all of the
local custom bits in local repos. When you make a generic change, pull
it into each of the local repositories and then do an hg update to
combine the changes into the running config.

This of course is only two layers: global and local. To add a third
layer, foo, create a new repo that you pull the global changes into
and that you add the foo-specific changes to. Then everyone who wants
the foo changes pulls from foo rather than global. And so on.

> > I want to store the configuration of some server in subversion. There
> > are files I want to keep in sync on all servers (e.g. /etc/resolv.conf),
> > and there are files which will never be the same on any two severs
> > (e.g. /etc/hosts) - and anything inbetween. Merging would probably
> > become a constant pain here, I guess...
> > 
> > So I wrote a simple layer-based approach. They are simply stacked on top
> > of each other; the file from the upmost layer is the one I work with.
> > When I change a file, it should be commited to the first layer the file
> > exists in.
> > New files can either be placed in a configurable default layer, or
> > require manual user specification (right now commit is not implemented
> > anyway; you can only sync, then cd to your real checkouts and commit
> > there)

-- 
Mathematics is the supreme nostalgia of our time.