Layered repositories

[Erich Schubert]

Hi,
> > 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.

It can easily be a separate repository, it can also be a subdir within
an existing repository, which is my current approach. It doesn't matter.

If it helps you understanding my question:
Does mercurial allow me to check out multiple repositorys into one
output directory and is still able to run update and commit nicely?
(i.e. update/commit files from/to whichever repostory they were from)

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

Bad choice, again.
I do NOT want to *manually* pull changes from one
branch/repository/whatever to another. I just want to "stack" them on
top of each other, have them flat in my UI and working directory, but
logically still separated in their layers?

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

Which sucks, because I need to manually pull.

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

Yeah, this is how branches work: you have to *merge manually*, which is
what I do not want, thank you.

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

Keeping a well-defined version is a way (albeit a different way than the
usual) of conflict resolution. I do need the "traditional" merge way,
too:
If a file was modified inside the "mail-server" layer and on the local
machine, and does not exist in a "higher layer", I need to merge these
changes (and eventually commit the merged version back to mail-server,
or into a higher layer)

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

Why should this be a requirement? It is not needed at all!
It might be a common case for source-code, but even there...

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

Yes, and B maybe also pulls from A2, A3, A4 and A5.

> Possible problem - file from B doesn't work in the new configuration.

Yes.

> The system doesn't tell you about it. You need to fix it then.

Yes. This can happen, so what?

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

That is why I didn't start with B=A, and btw. subversion handles this
very nicely without actually duplicating the files... *duck*

> The real last steps would be:
> - B pulls from A

No, it would probably more likely be
- A4 pulls from A5
- A3 pulls from A4
- A2 pulls from A3
- A pulls from A2
- B pulls from A

- C3 pulls from A4
- some magic star merge happens with A3,A2, C3 and C2 so the changes I
have made in A2 and that should also exist in C2 are merged with
whatever has changed in A3 and C3.
- C2 pulls from C3
- C pulls fom C2
- B2 pulls from C
[... repeat for more different layer configurations ...]

best regards,
Erich Schubert
-- 
    erich@(vitavonni.de|debian.org)    --    GPG Key ID: 4B3A135C   (o_
   There was never a good war or a bad peace. - Benjamin Franklin   //\
               Für jedes Problem gibt es eine Lösung,               V_/_
                  die einfach, klar und falsch ist.