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

[Markus Schiltknecht]

...continuing my thoughts on partial pull.

Hey, you're still with me ;-)  I promise, this is the last long mail of 
the partial pull series.


Having only parts of a repository brings up a whole lot of new questions 
regarding the user interface. But especially when thinking in terms of 
gaps instead of a horizon, that can probably be enlightening.

The most obvious ones to solve are 'mtn annotate' and 'mtn log': those 
should just print a placeholder saying: "here are some revisions 
missing" for a gap (not much different for partial pull).

It's less obvious what to do on 'mtn automate ancestors', for example. 
For partial pull with a horizon, we could simply stop at the horizon. 
But we should certainly emit a warning that there are more revisions, 
which we just don't have. With gaps, it's even more important to warn 
about missing revisions, but we can perfectly well continue after the 
gap and list more ancestor revisions.

It gets really complicated with commands which take a list of revisions 
as their arguments, for example 'mtn automate erase_ancestors'. 
Shouldn't those know about the gap? Certainly, those should be able to 
handle the output of other automate commands.

We basically have three possibilities when printing sets of revision 
ids, where gaps could be contained.

 1) don't print gap information - certainly the most compatible option, 
but this might lead to misinformation, i.e. an automate user not knowing 
that there are gaps in his set of revision ids.

 2) print a special marker, showing that there is a gap. Most probably, 
we would add the sentinel revision id, for example: 
"sentinel:d27ab397829c.." - this would break compatibility with existing 
code, but only for repositories with gaps.

 3) print the sentinel revision_id just like any other revision id, 
without a special marker - also quite compatible, except that subsequent 
automate commands on a revision id, like get_revision, might fail. This 
would require an additional automate command 'get_revision_id_type'.

I'm against option 1, but I can see reasons for 2 or 3, I'm not sure on 
that. And somehow they are quite close: both output the same set of 
information, except that option 3 needs an additional automate command 
afterwards.

Perhaps it's better to go for option 2 and consciously break 
compatibility, instead of only pretending it and silently fail afterwards.

What do you think? Did I forget any commands, for which behavior is 
questionable in presence of gaps?

Okay, here I'm closing my partial pull series. Thank you for following 
me all through 'till here. I'm looking forward to a constructive discussion.

Regards

Markus