Layered repositories

Radoslaw Szkodzinski astralstorm at gorzow.mm.pl
Sun Sep 18 03:30:36 CDT 2005


On Sat, 17 Sep 2005 15:50:00 +0200
Erich Schubert <erich at debian.org> wrote:

> Hi,
> > If there are no conflicts, the merge is automatic. There are smarter and less smart algorithms for it, of course.
> 
> There are cases where there will be conflicts, actually. E.g. I have a
> default postfix configuration for regular servers (which resides in the
> base layer), and a special one for the real mail servers (which resides
> in the mail-server layer). I don't want to see any merge happen there
> when I change the base version.

So you just put them in different branches. Each branch has an entirely separate history. You can merge to one branch only for instance. 
And if you want to make a branch merge, it's easy.

> Servers that have only the base layer will be updated to the latest
> version from base, servers that have the mail-server layer stick with
> the version from there.

This sounds like mail-server and base are separate repositories.
You probably just don't know that in mercurial, repositories are cheap, easy to set up, much unlike subwhatever.

The mail-server repository can (but doesn't need to; they're separate)
pull sometimes from base repository and if they diverge too much, you'll have to do the merge by hand.

Some pull mail-server repository, others pull base repository.

> 
> > You can't do without merging. Two people can always create incompatible changes and then you have to merge or discard one set of them.
> > Tell me how to avoid it entirely.
> 
> Check out laysvn. ;-)
> A very very simple rule:
> if the file was modified in the branch, it is not to be merged.

This is actually how branches usually work, but maybe not in subwhatever. To merge branches, you have to do it manually.
But there's still intra-branch merging involved.

Maybe we're talking about different kinds of merging. For me, merging means conflict resolution.

> That's why I called it layers: they *hide* what is underneath.

Real layers would be like this:
- there exists a base repository, lets call it A.
- you create another repository, lets call it B.
- B=A in the beginning.
- you do some changes in B.
- you do some changes in A.
- B pulls from A and doesn't update files which were modified in B.

Possible problem - file from B doesn't work in the new configuration.
The system doesn't tell you about it. You need to fix it then.

This is also ineffective, as you store more whole files in the repository B.

The real last steps would be:
- B pulls from A
And either:
- B give you a conflict to resolve, you modify the files accordingly
(some parts get merged automatically)
Or:
- B automatically merges changes using a merge algorithm (usually 
three-way merge)

Possible problem - you need to merge.

-- 
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/20050918/bdbc3919/attachment.pgp


More information about the Mercurial mailing list