Re: [Monotone-devel] README library list and log command fixes

[graydon hoare]

Nathaniel Smith <address@hidden> writes:

> I did notice an interesting quirk just now, fetching from Matt's
> depot; I fetched just from it, without doing a full fetch.  And
> because I hadn't fetched from www.off.net for a few days, I didn't
> have 5c7614b9a281dade7383a1af9cc550367f806157 in my depot.  Matt's
> changes were based off of 5c7614b9a281dade7383a1af9cc550367f806157, so
> I ended up with a fragmented revision tree.

by "a fragmented revision tree", do you mean:

 1. you received file or manifest deltas you literally could not apply?
 
 or

 2. you received a manifest with an ancestry cert pointing to a parent
    you did not yet have (and which subsequently resolved itself when
    you next fetched from www.off.net)?

the former would be a bug. if so please file it. monotone is supposed
to see that there is no manifest on matt's depot, so it should post
full versions. the latter is something I don't think we can reasonably
defend against. if you don't have some bit of history, you don't have
it.

anyways, if it's just this later case #2, I don't think it'll *harm*
you in any way other than making merges you do, between my head and
matts, degrade from 3-way to 2-way. and then, again, only until you
fetch from www.off.net to "fill in the blanks". 

the only other option I can think of is to have "starting a fresh
depot" involve posting all the way back to the beginning of history as
you know it. is that a good idea? I don't particularly like it -- it
means that someone trying to set up a depot with just a couple changes
might need to dump many megs of redundant packets on anyone pulling
from them -- but perhaps it is.

> This is related to the problems we solved earlier by using multiple
> redundant ancestry certs (though now that I think about it, I'm not
> entirely sure the solution always works when there are more than two
> depots and someone is fetching from some subset: say you have A1 -> B1
> -> C1 -> A2, and I am only fetching from depots A and B, won't I end
> up seeing A1 -> A2, A1 -> B1?). 

I'm inclined to treat parenthetical concerns like this from you very
seriously now :)

having thought this over a bit, I think you're once again spot on: the
queue_edge_for_target_ancestor function ought to queue not just the
edge (deltas + cert) from ancestor -> new, but also all the ancestry
certs along all the paths from ancestor -> new. in most cases this
will be exactly the same as the one ancestry cert, no harm done. but
in pathological cases it'll keep a 3rd party monitoring an incomplete
set of depots from seeing a fork where there isn't one.

nice catch. I'll try to cook up another testcase demonstrating this,
along with a fix.

-graydon


(though, it's not as critical as the criss-cross merge issue; I think
 in this case the 3rd party could probably 3-way merge the problem
 away. it's still annoying that they might have to do so..)