Layered repositories

Eric Hopper hopper at omnifarious.org
Thu Sep 22 11:18:22 CDT 2005


On Fri, Sep 16, 2005 at 08:40:28PM +0200, Erich Schubert wrote:
> 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)
> 
> One special rule: if a file is ignored in a certain layer, all layers
> below are "hidden".  So I can remove files by ignoring them in a
> higher layer.

This is an unusual set of requirements, and I think no matter which
version control system you opt for, you'll have to stack some of your
own code on top of it to make it work.

On the surface it sounds like having several Mercurial repositories that
are all branches of eachother would be the way to go.  I can definitely
see cases where some changes to your base postgress configuration (for
example) should be percolated up to your mailserver's postgress
configuration, even if most of those changes shouldn't be.

Your branch structure would be something like:

          /--mail server-->
-----base------->
          \--DNS server-->

etc...

You would then merge changes from your base to your mail server whenever
you made a change.  Files that you made no changes to in the mail server
branch would be merged automagically.  Files that you did may or may not
have to be hand merged.

It probably be nearly a complete solution to your problem if there was a
merge option that said "Ignore changes made to files I changed on the
branch."  In fact, I expect that it would be possible to convince hg's
merge command to do just that given that you can write your own hgmerge
and have it work.  But, that's speculation on my part just now.

Another option would be to have a single repository with all the
different configurations in their own subdirectories and a little shell
script that automatically pulled them all together.  You'd have to have
a special entry for an ignored file though.

I've been using Mercurial to track my config files.  I use it to track
the default configuration shipped in the rpm on a branch.  So when I
upgrade, I just merge that branch back in.  It makes it much easier to
see which are the vendor's changes and which are mine and how to blend
the two.

Anyway, it's possible you already understand all this, but there seemed
to be multiple misunderstandings in both directions in the ensuing
discussion, so I wasn't sure what the final outcome was.

Have fun (if at all possible),
-- 
"It does me no injury for my neighbor to say there are twenty gods or no God.
It neither picks my pocket nor breaks my leg."  --- Thomas Jefferson
"Go to Heaven for the climate, Hell for the company."  -- Mark Twain
-- Eric Hopper (hopper at omnifarious.org  http://www.omnifarious.org/~hopper) --
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.selenic.com/pipermail/mercurial/attachments/20050922/4b3ee953/attachment-0001.pgp


More information about the Mercurial mailing list