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

[Markus Schiltknecht]

Hi,

Thomas Keller wrote:
> The question is: Do we care if automate commands spit out those revision 
> ids or not? Shouldn't this be up to the user / client since he knows 
> best what to do with such a revision id?

Yeah, that was my question. I take this as a vote for option 3.

> We could also add an option "--no-sentinal-revs" to most of these 
> commands to be able to filter them out quickly in case we're not 
> interested in a complete graph without gaps.

That seems awkward. Please let us settle for a clear logic: either 
revision id's can contain sentinel ids or they cannot, period.

> > 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]
> > .
> > .
> > .
>
> Thinking a bit more on this I tend to say that its completly impractical 
> to introduce another revision format.

Why is that? What's the format_version for, then?

> We always assume that a revision_id is the sha1 hash of the revision 
> text behind it.

This assumption is certainly only true for real revisions and not for 
sentinels, no matter how we store them.

> If we now introduce a "pseudo format" for a gap revision 
> we'd effectively have to change the revision_id of that revision so the 
> revision is valid after all and therefor also have to change all 
> descendant revisions as well, _each time_ we pull a bit more history. I 
> don't think this is practical.

Agreed, that's certainly impractical. But leave away the hash check for 
sentinels and it gets very well possible.

Or put it another way: we need to store the sentinels somewhere, their 
format is quite similar to that of a revision and we run into problems 
with automate. So why not make it the same format?

Don't get me wrong, we should certainly put the real revisions into the 
table 'revisions' and sentinels in 'sentinels' - primarily to be able to 
distinguish quickly between real revisions and sentinels - but also to 
maintain the hash validity property of the real revisions.

> What could a gap revision text tell us 
> after all if we don't want to pull the revision's text beforehand as 
> well?

Please have a look at the wiki page, to get an idea about what exactly 
needs to be stored for a sentinel. Adding the revisions a gap contains 
is just a possible addition, which I'm questioning as it only helps a 
few automate commands and server not much else.

Also keep in mind, that the reason for partial pull is saving bandwidth. 
Not having to fetch all the revision texts, but just a sentinel 
definition, is a huge gain.

> We just have the history relations, and that's all. To get this 
> info, people could just call automate 
> parents|children|graph|ancestors|descendents.

That would pretty much render partial pull useless. The 
bang-for-the-bucks ratio of the relations history is pretty minimal. 
People often want *files* not history information, heck, most people 
probably don't even know about mtn automate.

> So, in the end I'm for just issueing an error if get_revision is called 
> for a gap revision.

I agree on that as long as we have corresponding 'mtn automate 
get_sentinel' and 'mtn automate get_revision_type' commands. This would 
be option 3.

But then again, that doesn't look so charming... lots of commands for 
almost the same thing: getting the data we have for a revision id.


Let's call the revision text format_version increment variant our option 
nr. 4.  I'm currently favoring that somewhat, as it seems to be the most 
backwards compatible option we have.

Regards

Markus