Re: [Monotone-devel] partial pull #2 - gaps instead of a single horizon

[Timothy Brownawell]

On Mon, 2007-05-28 at 18:59 +0200, Markus Schiltknecht wrote:

> > We can't verify it, so we have to trust it. Which means we need to know
> > who it comes from, so that that can be an informed decision. Which means
> > that it either needs to be signed, or we need to track which server it
> > came from and not allow servers to provide this data unless they
> > generate it from a full history graph themselves.
> 
> Wow. Do you really want to have all that trust stuff for partial pull? I 
> mean, it's quite simple to verify your data, you just need to download 
> the whole history...
> 
> OTOH, for my extended use cases, like hot server or such, that would 
> probably make sense.
> 
> >> Though I don't quite get your argument about rewriting history. In what 
> >> way would history-collapsing allow something that's impossible otherwise?
> > 
> > If there are gaps in the history graph, we can't know that it's
> > well-formed. We can usually verify this because a child contains the
> > hash of the parents, but if we allow holes in the graph we need some
> > other means to connect ancestor<->descendant across the hole. And since
> > we can't *know* that it's correct without having all intermediate
> > revisions, whoever tells us what that relationship is has the power to
> > rewrite history.
> 
> Well, at least he would still have to break the hash. So that's not such 
> a big concern, IMO.

Why would they have to do that? A revision contains (1) the hashes of
parent revisions, and (2) names/hashes of modified files. If we don't
actually have the parent revisions, we have to take (1) on faith, and
suddenly don't know anything about the contents (or even presence) of
files not included in (2).

So if, say, Makefile.am hasn't been changed in any revision after the
gap, whoever provides us with the HC-revision can make it say whatever
they want. Including things that cause "make" to compile and run files
that were never added in the real history. So we need to trust the
HC-revision at least as much as a real revision, and possibly more since
it can break the assumption that later committers knew what they were
committing.


-- 
Timothy

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