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

[Thomas Keller]

Markus Schiltknecht schrieb:
> 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.

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?

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.

> 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. At first I assumed that something like


format_version "1"

new_manifest []

old_revision [0010f6d6eb621cf5eea7b73676c17295ed6961cd]


would be enough to define a sentinel revision (the empty new_manifest 
stanza could be used as flag), but then I realized that two sentinal 
childs of one and the same revision would lead to the same pseudo 
revision and therefor couldn't be distinguished textually. But your 
approach (obviously I don't understand why you list all these 
revision_sentineled stanzas) doesn't seem to be better for another reason:

We always assume that a revision_id is the sha1 hash of the revision 
text behind it. 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. What could a gap revision text tell us 
after all if we don't want to pull the revision's text beforehand as 
well? We just have the history relations, and that's all. To get this 
info, people could just call automate 
parents|children|graph|ancestors|descendents.

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

Thomas.

--
ICQ: 85945241 | SIP: 1-747-027-0392 | http://www.thomaskeller.biz
> Guitone, a frontend for monotone: http://guitone.thomaskeller.biz
> Music lyrics and more: http://musicmademe.com