Re: [Monotone-devel] partial pull #3 - calling conventions

[Markus Schiltknecht]

Hi,

Thomas Keller wrote:
> I'm not completly in this topic, so I might be perfectly wrong, but 
> wouldn't it be possible to just fetch the revision_id graph and leave 
> out revision texts, roster and file data for gap/unfetched revisions, 
> just mark them in a special way? This way we'd still have the relations 
> needed by automate ancestors, common_ancestors, graph, aso., and reduce 
> the whole problematic to those functionalities which actually _need_ to 
> know about revision texts and/or rosters (like log, annotate).

Yeah, I had the same idea. And for small gaps, that's completely 
feasible. For partial pull, it's at least up to discussion. Some numbers 
for that, on net.venge.monotone:

$ mtn automate ancestors `mtn automate heads` | wc -l
6816
$ mtn automate ancestors `mtn automate heads` | wc -c
279456
$ mtn automate ancestors `mtn automate heads` | gzip | wc -c
158604

So a gap from the head to the root, as a partial pull could require, 
would have to fetch 6816 revision ids, which weight ~ 150 KB compressed.


The thing is, knowing these revision id's does not really solve the 
problem. If we allow the automate commands to spit out all the rev ids 
within a gap, it still outputs revision ids which are not in the repository.

A 'mtn automate get_revision $REVID' on such a rev id will fail. Except 
you are going into a completely different direction: adding another 
revision format, which could include these gaps. Then 'mtn automate 
get_revision $REVID' would for example show:


format_version "2"

type "sentinel"

new_manifest [74c1f552e0b36503edd20164a8c6cc8601010470]

height_covered "206"

revision_sentineled [0010f6d6eb621cf5eea7b73676c17295ed6961cd]

revision_sentineled [001371a4c101b5064480ccf32cdb16563c9ba6a9]

revision_sentineled [0018767555f7e2d2fe8d3b50ff3ad2a54f6d4783]

revision_sentineled [0031892be77daf402965c25394423fe54e499d1a]

revision_sentineled [003687b087a1f4358d2caa795645b45cb6cf3d1e]

revision_sentineled [005684f8690d9c68d4177fcd73baec282ce69da4]

old_revision [3c3ae55c27f65ea303e1d173ab1f2f29756c6571]

patch "po/es.po"
 from [e17da89bc930cbce44e2df811099abe83f2481b9]
   to [a9c75b19107f35c8aef74870873c03b88289f6f2]
.
.
.


This would be somewhat backwards compatible: by incrementing the 
revision format_version, we show that something has changed.

Hm.. I somehow like that idea. But it's even more of a dramatic change...

Regards

Markus