monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] partial pull #1 - only two revision types, please


From: Markus Schiltknecht
Subject: [Monotone-devel] partial pull #1 - only two revision types, please
Date: Fri, 25 May 2007 10:39:37 +0200
User-agent: Icedove 1.5.0.10 (X11/20070329)

Hi,

on the summit, I've loosely followed the partial pull discussion. Just now, I've had another look at the wiki page and the n.v.m.partialpull branch. I'd like to continue that discussion. The wiki page [1] describes the current proposal, if you need more information. I'm splitting into multiple mails to structure the (hopefully following) discussion somewhat.


The current schema in n.v.m.partialpull introduces *two* new tables: sentinels and horizon_manifests. For most of the rosters code, that results in three types of revisions which have to be treated differently:
 - normal revisions, for which we have all ancestor revs
- just-below-horizon revs, where at least one ancestor rev is missing, but where we should have a special horizon_manifest
 - sentinels, for which we cannot build rosters (missing revs)

I'm suspicious about the just-below-horizon revs. Let's just leave them away. That simplifies matters a lot: we either have revisions, for which we have all the data (including rosters) - or we have a sentinel, for which we are missing data.

The wiki page tries to give a reason for the existence of just-below-horizon revs: "there is utterly no point in having any more than this -- we could get it a little higher up, like we could send the A B C manifest+ids, but then we'd just have to turn them into rosters in memory to create the E D F rosters, but then not write the A B C rosters to disk... pointlessness."

So, as far as I understand, having this third type of revisions, which needs to be treated specially in non trivial parts of the code, saves us the transfer of some manifests+ids during a netsync? IMO, this is a micro optimization which is not worth it. Let's just send that additional data, even if we only partly need it.


To be continued...

Markus

[1]: monotone wiki, partial pull:
http://www.venge.net/mtn-wiki/PartialPull




reply via email to

[Prev in Thread] Current Thread [Next in Thread]