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.
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:07:18 2007