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

[Markus Schiltknecht]

Hi,

Timothy Brownawell wrote:
> I was thinking that it would be a completely ordinary revision, with the
> appropriate revision_id for its text, except that it would be
> accompanied by a statement from the server (maybe just a new type of
> special cert?) of "This is history-collapsed revision, which can be used
> as a replacement for da39....", and then you have a lookup table
> somewhere that records this for use by things that walk history and
> might need to look at da39....

I don't understand why you want to do things so complicated. What gain 
would the hash of the sentinel text data give us? Or the special cert? 
It's not like we need to verify correctness of the sentinel data - we 
can't anyhow since we are missing the real revision data.

The main reason for the sentinels is, having a quick database lookup for 
monotone to know what's missing where. Think of it as an internal 
format, we are certainly never exchanging sentinel data via netsync. 
It's much more probable that we transmit something like 'node X is only 
interested in revisions of the last two months'.

> (You'd also want to disallow committing an immediate child of a
> history-collapsed revision, since they're basically a way to allow
> rewriting history.)

Since it's impossible to check out a sentinel revision (as you don't 
have all the data needed for it) it's impossible to commit a child to 
it, too.

Though I don't quite get your argument about rewriting history. In what 
way would history-collapsing allow something that's impossible otherwise?

> > Uhm.. I remember Nathaniel saying, that mark merge might be tricky with 
> > multiple (>2) ancestors. And as we would have to be able to provide a 
> > roster for the gap, we need to provide those markings.
>
> But we already know what value we're going to end up with. ...although
> we still have to be able to determine if it should be marked, which I
> guess means we would have to upgrade to deterministic *-merge.

Sorry, I don't know enough about *-merge, yet, to discuss about that.

> > But theoretically, think of replacing all revs in a gap with a single 
> > revision. You could have committed it all in one go, no? That's how I'm 
> > thinking the sentinel could 'trick' the merge algorithm (and a lot of 
> > the rest of the monotone machinery).
>
> What about a wide gap?
>
> a       b   c
>  \     /    |
> ------------------
>    \ /      |    ^
>     d       e    |
>     |\    /      G
>     |  \ /       A
>     f   g        P
>     |   |        |
>     :   :        |
>     |   |        v
> -------------------
>     h   i
>
> The gap has two heads, so it needs at least two revisions to replace it.

Sure, so what's the problem?  You would simply add sentinels for f and 
g, while h and i are the first real revisions you have. Both sentinels 
would have the very same set of ancestors, namely a, b and c.


> a       b        c
>  \     / \      /
> --------------------
>   \  /     \  /
>    G1       G2
>    |        |
> --------------------
>    |        |
>    h        i
>
> But if you added a file in d, then this has it being added twice, as two
> separate files. So you need an extra revision:

Nope. G1 and G2 would both have the same node id for the added file. 
Thus monotone should be able to not add it twice.

> > How much do we need to preserve? Well, all the files which were added in 
> > *any* of the revisions in the gap. But none of the revision texts 
> > themselves. That's the goal of partial pull: only pull the files and not 
> > care about historical information.
>
> Or I suppose you could just say that if you want to merge, you need
> complete history back to all minimal common ancestors.

Maybe, but why restrict users unnecessarily ;-)

Well, I probably need to get my hands dirty, before claiming that 
everything is possible...

Regards

Markus