monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: netsync branch differences


From: Timothy Brownawell
Subject: Re: [Monotone-devel] Re: netsync branch differences
Date: Fri, 23 Feb 2007 07:18:41 -0600

On Fri, 2007-02-23 at 10:14 +0100, Lapo Luchini wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Markus Schiltknecht wrote:
> > grml% mtn sync venge.net "net.venge.monotone*"
> > mtn: bytes in | bytes out | revs in | revs out
> > mtn:   24.4 k |    53.0 k |     0/0 |      6/6mtn: operation canceled:
> > Interrupt
> > 
> > grml% mtn sync venge.net
> > "net.venge.monotone.cvsimport-branch-reconstruction"
> > mtn: bytes in | bytes out | revs in | revs out
> > mtn:  105.8 k |   178.2 k |     0/0 |    59/59mtn: operation canceled:
> > Interrupt
> > 
> > Why does first sync push only 6 revisions, while the later, more
> > restricted to one branch suddenly wants to push 59? Do I need to run a
> > mtn db check?
> 
> Because in the second example the Merkle trie is build only with the
> branch's revisions (also on server side!) and those extra 53 revisions
> are probably revisions from other branches that the server doesn't know
> it already has (because it was examining only that specific branch).
> Filtering on all the branch dependencies gives it a bigger vision and
> those 53 are noticed to be already at the destination.
> 
> Or at least, this is my current understanding of it, and is probably
> inaccurate (because in that case the server could know those extra 53
> are needed as well as the client does! so it must be slightly more
> complicated than this).

The server can only know about those revisions if either they or their
descendants match the sync pattern. So if you propagate some branch
into .cvsimport-... , the client will include those revisions because it
has their descendant that's in .cvsimport-... , but since the server
doesn't have that revision, it doesn't know to include the revisions in
the other branch.

We know a way to fix this (use dag-based refinement instead of merkle
refinement for revisions), but since it doesn't actually break anything,
and since changing the netsync protocol is a pain, it's just floating
around waiting for us to need to change netsync for some other reason.


-- 
Timothy

Free (experimental) public monotone hosting: http://mtn-host.prjek.net





reply via email to

[Prev in Thread] Current Thread [Next in Thread]