David Glasser wrote:
> On 10/19/07, Stefan Küng <tortoisesvn@gmail.com> wrote:
>> Hyrum K. Wright wrote:
>> [snip]
>>> Stefan proposed elsethread an API which allows consumers of
>>> libsvn_client to see the server's capabilities. How would a GUI handle
>>> that? Would you need to have additional user interaction, or just a
>>> warning that the server isn't adequate, therefore the output isn't as
>>> actuate as it otherwise would be.
>> That depends on what the GUI uses the API for. If a client can ask the
>> server what it can and can't do, that helps a lot when designing the UI
>> and showing hints to the user.
>>
>> An example from 1.3.x days:
>> the 'svn log --limit' worked with 1.3.x servers, but was terribly slow
>> when done with < 1.3 servers because the svn library then would fetch
>> the whole log (for the specified revisions) and just filter out those
>> which were too much.
>> If I could have asked the server with a (relative) fast call to an API
>> first if the server could do the --limit, I could have changed the "Next
>> 100" button behavior in the log dialog accordingly:
>> * if the --limit was supported, fetch logs from lastfetchedrev to 0,
>> with limit 100
>> * if the --limit was not supported, fetch the logs from lastfetchedrev
>> to lastfetchedrev-100
>>
>>
>> I don't know why you care about *how* a GUI client would use such an
>> API, because that's usually not really known before an API exists. All I
>> can tell you is that such an API would be a big help: there are always
>> such cases as I described above. And with such an API available, I'm
>> sure I'll find other cases where I could make very good use of it.
>>
>> with the svn_client_suggest_merge_sources API, I would first check
>> whether the server supports merge tracking.
>> * if yes, use the svn_client_suggest_merge_sources API to fetch
>> suggested source urls, then show those to the user in the merge dialog
>> * if not, don't call the svn_client_suggest_merge_sources API and let
>> have the user enter or select the source urls manually
>> Because: without the server support for this, the
>> svn_client_suggest_merge_sources API call is terribly slow and can't be
>> called while initializing the merge dialog - it would simply take way
>> too long.
>>
>>> The idea here is similar, except we use the error mechanism to
>>> communicate the insufficient server version, instead of an explicit API.
>> I don't like the idea of trial-and-error to find out whether the server
>> supports something or not. Because that behavior could change without
>> notice. I'd rather have a specific API to ask for that information.
>
> These aren't competing options.
>
> We would use the new capability API to implement a mergeinfo capability.
>
> If you want, you can check it first before making other API calls.
> (Maybe this means we need to expose capabilities at the client level,
> not just at the depth level.) But if you don't, the client lib should
> check it and error out if it can't be supported.
No, you misunderstand me. I don't want the library to *not* try the new
capability API. All I want the check for is to know whether an operation
is fast or slow. Because that's a very important thing to know - slow
API calls can't be used in certain situations (the UI must be responsive
and fast, no matter what).
And because the client API silently works around missing server
capabilities by doing sometimes *very* lengthy operations, I can't
decide beforehand whether an API call is fast or slow.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 19 21:23:36 2007