VCS Interfaces, round 3

[Matthew Woehlke]

Andreas Pakulat wrote:
> On 04.05.07 11:24:46, Matthew Woehlke wrote:
>> ...which still leaves the question of how do you specify the limit?
> 
> Simple unsigned int. If its 0 fetch all revisions, any number larger
> than 0: Fetch that many revisions from the repository.

Hmm, I guess no one will have more than four billion revisions? :-) 
(Given that long-lived products seem to be in the hundred-thousands 
range that is probably safe until KDE 5 at least ;-).)

>> Come to think about it, it would be ideal if VcsJob provided a way to 
>> return results incrementally.
> 
> We can follow QProcess here and emit resultsReady() then the user of the
> job can fetch the results and finished() would be emitted when the job
> is completely done.

Sounds good. I assume resultsReady() is fired 0 or more times? (I.e. 
keep firing it at results come in, possibly rate-limited? The rate limit 
would also be nice if the operation completes really fast, you would 
skip right to finished().)

>> Support would be optional, but if 
>> available it would allow
> 
> Uhm, the signals wouldn't be optional, but if the backend doesn't allow
> to send intermediate results it would send resultReady() just once and
> finished() immediately afterwards.

That's what I meant. If it doesn't know how to give intermediate 
results, it never uses that signal. :-)

>> e.g. filling in a UI as information is 
>> retrieved rather than having to wait for everything before anything can 
>> be displayed. (This brings up another point; a VcsJob should be 
>> cancelable :-).)
> 
> Cancellable is a must, yes.

I thought so. :-)

> It might however mean that the backend still
> executes completely, just that no resultsReady signal is emitted and the
> finished signal not either (rather a cancelled() one)

That's fine. I imagine process-based implementations will just SIGINT 
the child in this instance.

Do we really need a canceled() signal?

>> Another question: shouldn't the interface provide default parameter 
>> values where appropriate? For example:
> 
> Yes, sure. I didn't think about those yet thats why I left them out.

Ok, I'll start adding those when some of the other dust settles. :-)

>> virtual VcsJob diff( const QVariant& localOrRepoLocationSrc,
>>                       const QVariant& localOrRepoLocationDst,
>>                       const VcsRev& srcRevision = VcsRev::Working,
>>                       const VcsRev& dstRevision = VcsRev::Base,
> 
> Oh yeah, thats good. Exactly what I was complaining lately about 3.4's
> svn support ;)

Hmm... so it is. ;-)

Note that this implies static VcsRevision instances (kind-of like QColor 
Qt::red) on VcsRevision, or wherever seems appropriate. But we should 
have those anyway, having to construct a VcsRevision for HEAD, BASE, etc 
would be annoying. :-)

-- 
Matthew
Current geek index: 62%