[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] README library list and log command fixes
From: |
graydon hoare |
Subject: |
Re: [Monotone-devel] README library list and log command fixes |
Date: |
19 Oct 2003 17:41:44 -0400 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
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..)