VCS Interfaces, round 3

[Andreas Pakulat]

On 04.05.07 11:24:46, Matthew Woehlke wrote:
> Andreas Pakulat wrote:
> > On 04.05.07 10:17:40, dukju ahn wrote:
> >> For example, subversion takes 2~3 extra flags that are very useful
> >> (such as limit the number of log,
> > 
> > That will be included in the interface as its really useful.
> 
> Hmm, do you really think it is necessary?

Yes, its very important.

> Even on a huge project I don't think retrieval takes that long (unless
> you have a /really/ slow connection),

Uhm, I've got DSL6000 here and a full log of the qmake manager in
KDev3.4 takes more than just a few seconds. (Although I guess the
bottleneck is the SVN server and possibly the HTTP protocoll). I had
ISDN in my last appartment and that is damn slow for stuff like that. 

In case anybody is interested:
andreas at morpheus:~/KDE-work/kdevelop/buildtools/qmake>time svn log >/dev/null

real    0m32.978s
user    0m0.076s
sys     0m0.020s

If I'm just interested in the last 10 commits this is certainly
unacceptable for quickly looking at the log.

> the issue is usually displaying it. And I don't see a 
> problem there, we aren't talking about a console window. :-)

No, the issue is the time until I can see the log, displaying it in a 3
line window is not a problem, you've got less for that.

> ...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.

> 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.

> 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.

> 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. 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)

> I realized just now, log() should take a VcsRevision also (should it 
> not?),

Didn't it had one some time ago? 

> 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.

> 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 ;)

Andreas

-- 
Avoid gunfire in the bathroom tonight.