VCS Interfaces, round 3

[Matthew Woehlke]

dukju ahn wrote:
> 2007/5/4, Matthew Woehlke <mw_triad at users.sourceforge.net>:
>> 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? Even on a huge project I don't
>> think retrieval takes that long (unless you have a /really/ slow
>> connection), the issue is usually displaying it. And I don't see a
>> problem there, we aren't talking about a console window. :-)
> 
> That's very useful. For me, it takes more than 1 minutes to see
> the _full_ logs for KDE repository even in _konsole_. I live far from
> germany and internet connection is slow. And not all KDE committers
> don't live in europ. My case is just a real example. KDevelop should
> cope with various circumstances.

True, although depending on your connection, it isn't unreasonable for 
the tty to be the bottleneck. At T1 speeds I find that usually log() 
completes much more quickly if something else is consuming the output 
(e.g. grep, or /dev/null).

>> But I guess I don't see a problem, a VCS that can't limit the result
>> (um... like I don't think perforce does it, at least it doesn't seem to
>> do it /correctly/ even though it claims it can) can either artificially
>> strip the results or (my preference) simply ignore the limit. IOW the
>> limit would be advisory.
> 
> Then how about making the argument just a recommendation?
> The caller can specify limit arguement, but there is no guarantee
> that actual returned result is limited to given arguement.

Isn't that exactly what I said? :-) Yes, that would be fine.

Please continue pointing out any extra flags that might be portable that 
you think should be in IBasicVC.

> Anyway limiting argument example in log() was just one example to
> question how each VCSs can maintain its full flexibility that is offered
> by origianl VCSs. In summary, we can derive ISubversionXXX. And
> showCommit() showLog() showDiff() methods can invoke its own
> option dialogs. But the other methods (commit(), log(), diff() or
> copy, move, revert, update) should not invoke any GUI.
> Did I summarized correctly??

I think so, when showFoo() exists, it invokes a UI and foo() does not. 
You are implementing both, so adding function to showFoo() is easy. 
Adding function to foo() is done by providing an overload of foo() that 
takes additional arguments. Such an overload is only available in e.g. 
ISubversionVersionControl (i.e. not in IBasicVersionControl). You can do 
the same with showFoo() if you need to pass default arguments.

Should showLog() take a limit, or use a default value with the ability 
to make incremental calls to log() in the same UI instance if requested?

-- 
Matthew
Current geek index: 62%