Layered repositories

Radoslaw Szkodzinski astralstorm at gorzow.mm.pl
Thu Sep 22 10:01:42 CDT 2005


On Thu, 22 Sep 2005 16:38:59 +0200
Erich Schubert <erich at debian.org> wrote:

> Hi,
> > It will hide them. The last revert will overwrite.
> 
> With "hiding" I meant *removing* files in a layer, that were present in
> a lower layer. Of course I often could do that with an empty file - e.g.
> in cron.d - but that is not always possible, and not the nicest way...

It's easier than you think. Just remember to add all needed files (even from other branches) to the given one and do a typical hg update -C.
(without the reverts).

This will make stacking impossible however. I've thought of another way: you could just merge the common files between branches with hg rawcommit. (say - multiple parent commits) Then of course you have to resplit the branches which you merged.

> 
> > Well, yes, using rawcommit with -p option I think. If you mean
> > committing them to another head. If not, then just a simple hg add, 
> > hg commit will do what you want.
> 
> yeah, thats what I need: if I change a file from the base layer, it's
> likely that I will want the same change on all machines; when I change a
> file which is in the mail server layer, I'll probably only want it on
> the mail servers. Otherwise I'll likely have to do the same change in
> two versions of the file anyway, or I should remove the file from the
> upper layer if they don't differ (anymore).

You can really remove everything else (including all lower layers) by just hg update -b <branch>. However, you can merge in some files between branches (just a correct hg rawcommit) and still keep local changes.

> 
> > But that's why I've told you that for development, you'd better have
> > multiple repository copies, each showing a different branch of the
> > repository.
> 
> Yeah, but I'm not using it for software development, but for
> maintaining, updating and especially logging and archiving the
> configuration of servers.
> 

Each server uses one checked out repository, yes? Read: one branch checked out. You can change base on it of course, but it's not as simple as changing the base on the serevr, where only base is to be used.

> 
> Now back to my original question:
> How hard is it to add such functionality to mercurial? ;-)
> 

Given current plugin architecture, it's quite easy I think.
The code itself is very readable (thanks to Python).

hg status could use some branch knowledge. The same with hg revert.
Maybe hg rawcommit could be a bit simplified?
You can always add your own commands. (see Mercurial Queues for an example)

-- 
GPG Key id:  0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0  9105 9543 0453 D1F1 0BA2

AstralStorm
-------------- 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/a33e9f87/attachment.pgp


More information about the Mercurial mailing list