[Top][All Lists]
[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