Re: [PATCH] Re: log/blame -g and old servers

On 10/19/07, Stefan Küng <tortoisesvn@gmail.com> wrote:
> David Glasser wrote:
> > On 10/19/07, Stefan Küng <tortoisesvn@gmail.com> wrote:
> >> 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.
> >
> > That's exactly what I said. "If you want, you can check it
> > [capabilities] first before making other API calls."
>
> How can we check this without such an API?

See the next sentence.
"(Maybe this means we need to expose capabilities at the client level,
not just at the [ra] level.)"

Note that I meant ra, not depth :)

We are in agreement I think...

--dave

-- 
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org