erich at debian.org
Sun Sep 18 05:43:09 CDT 2005
> > 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,
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.
> 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 ...]
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.
More information about the Mercurial