states/phases plan: exchange boundary
mpm at selenic.com
Mon Oct 10 11:52:53 CDT 2011
On Mon, 2011-10-10 at 01:51 +0200, Pierre-Yves David wrote:
> After a push or a pull they might still be changeset that belong to
> local or remote only. Those exclusive changeset might be part of the
> boundary If the boundary are exchanged as is, unknown node can't be
> processed. They might be ignored or the exchange logic may try to find
> a common ancestor for this node.
> ** initial state **
> Here is a small example
> / E
> A - B - C - D
> The local boundary is [B]
> / E - F
> A - B
> The remote boundary is [F]
> ** We push local to remote **
> Local is unchanged and remove now look like this
> / E - F
> A - B - C - D
> The remote boundary is [F, D]
And that happened why? The remote server is publishing?
Remember, Bitbucket -today right at this very moment- needs to be a
fully-functioning publishing server. This is how we stay compatible with
the thousands of servers that are already out there: pushing to an
old-style server means publishing.
So what makes a publishing server? Simple: complete lack of tracking of
the liquid barrier. So here the client does:
- check for liquid phase barrier via listkeys
- no? ok, mark our just-pushed changesets published locally (easy)
But let me try your question a different way:
a-b liquid roots = [a]
Non-publishing server has:
a-c liquid roots = 
The correct result is:
a-c liquid roots = [b]
How do we get this result, given that the client doesn't know what c is?
Simple: the client doesn't even need to look at the server's liquid
barrier, it just pushkeys the liquid roots inside the set it's sending.
Here it says "by the way, in those changesets I just pushed, b and all
its ancestors are liquid". The server's pushkey method has all the
information it needs to merge those into its liquid barrier.
Now what if client had:
a-c liquid roots = [a]
And server had:
a-c-d-e liquid roots = [d]
Should the client learn that c is frozen when it pushes b? I would say
no, that's not essential. Note that this sort of thing will only happen
if you don't pull before you push, for instance if b is on a new named
But it's also totally possible to infer: local head c is not in the push
set, is not excluded from the push by -r, and is not covered by the
remote liquid roots. So it must exist on the server and must be frozen.
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial-devel