Mark Phippard wrote:
> On 10/19/07, Hyrum K. Wright <hyrum_wright@mail.utexas.edu> wrote:
>> David Glasser wrote:
>>> On 10/12/07, Karl Fogel <kfogel@red-bean.com> wrote:
>>>> "David Glasser" <glasser@davidglasser.net> writes:
>>>>> Here's a patch implementing that for ra_svn. (Presumably, the same
>>>>> patch for DAV will be harder because of the general lack of
>>>>> capabilities.)
>>>> As we were discussing in IRC: detecting capabilities will be easier
>>>> after I commit my patch for issue #2959 (latest patch attached there
>>>> for inspection).
>>> Now that we have this, do people support adding a mergeinfo capability
>>> and using this to (among other things) error out on log/blame -g?
>>>
>>> I'm not sure what I feel about Mark's argument about wanting to
>>> hardcode to the -g equivalent. Maybe the svn_client APIs could return
>>> a boolean saying whether or not mergeinfo was actually used?
>> My initial reaction was not to produce an error, but now I'm not so
>> sure. If I run 'log -g' on an unknown server, I'll get different
>> results, depending on whether that server is pre-1.5 or not. Producing
>> different results dependent upon server version is Bad (at least in this
>> case).
>
> That is like saying running this command on a range of revisions with
> no merges gives different results. It gives the information it has.
Correct. But if I'm a user, and I want to see what has come in as a
result of a merge, I run 'log -g'. Against a pre-1.5 server, that won't
show anything that has come in, which is not correct, and not what I'm
expecting. If we want merge auditing to be "maybe you'll get it, maybe
you won't, and you don't have a way to determine which one it is", they
proceeding silently is acceptable behavior.
>> I now feel that producing an error here isn't a problem. Clients can
>> trap the error and take whatever action they feel appropriate, which may
>> include informing the user, and reissuing the request. I suspect the
>> command line client would just error out.
>
> Spoken like a command line user. So do you think we should change all
> GUI's to always just run svn log, then make you take a second option
> to re-run it with the merge info included? Or should we remember that
> is what you wanted, and instead let the tool generate errors and force
> you to turn the feature off? Or always run the command, get an error,
> dynamically change the setting and try again? This would be a good
> product?
I am a command line user; you've caught me red-handed. :)
What I'm proposing (and again, I don't have much experience with the GUI
clients) is that the clients run log and look for errors. If the error
occurs, run log again *but warn the user the data isn't as accurate as
it could be*. That doesn't involve any additional input from the user,
and has minimal UI implications.
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.
The idea here is similar, except we use the error mechanism to
communicate the insufficient server version, instead of an explicit API.
-Hyrum
Received on Fri Oct 19 20:18:34 2007