David Glasser wrote:
> On 10/19/07, Mark Phippard <markphip@gmail.com> wrote:
>> On 10/19/07, David Glasser <glasser@davidglasser.net> wrote:
>>> On 10/19/07, Mark Phippard <markphip@gmail.com> 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.
>>> A *repository* can be 1.5-y and contain mergeinfo without a particular
>>> server serving it being.
>>>
>>> In fact, this may be surprising, but *a lot of the new merge tracking
>>> features kind of work without a 1.5 server*. Currently,
>>> merge_tests.py passes cleanly with a trunk client and a 1.4.x
>>> svnserve. Only 4 of the 74 tests have a "skip this if the server
>>> doesn't support mergeinfo" tag!
>>>
>>> In the status quo, there can be a repository with mergeinfo in it that
>>> log/blame -g make appear to the user as if there is no mergeinfo if
>>> the server is old. This is a problem.
>> Why? Just saying it is a problem doesn't make it one.
>>
>>>>> 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 don't see what is wrong with the last choice here. This is how most
>>> of svn's compatibility code works. If you want to pass the new
>>> boolean to the API in Subclipse, then just wrap it in a try/catch and
>>> if a not-implemented exception is thrown, try again with it as false.
>>> You only need to do this in one place in your code if you want. I
>>> don't see how this is a large burden. (As far as efficiency goes,
>>> Karl's capabilities implementation makes a capability request happen
>>> at most once per RA connection.)
>> So in a GUI tool it is OK to have checked an option that says you want
>> to see the merged revisions, but then not see them? I think the
>> answer is Yes by the way. But this contradicts the previous problem.
>> The difference is that a command line user has to type -g. A GUI user
>> might have set some preference somewhere. It is different. In the
>> case of Subclipse, we have a History view that can be open that even
>> automatically tracks your editor. So as you open a file the view
>> shows the history for that file. Getting errors here would be
>> unacceptable.
>
> I think we are talking past each other.
>
> There are four things communicating here:
>
> Server <-> Client libs <-> Subclipse <-> User
>
> I am in no way telling you that Subclipse should give the user an error.
>
> I am saying that the client libs should give Subclipse an error. If
> you think the right thing to do is for Subclipse to immediately ask
> the client libs the same request but with use_mergeinfo=false, all
> power to you.
>
>> Why can't the command line just error out if -g is used but leave the
>> API itself alone?
>
> That's impossible! What the command-line does is *call the API*. If
> you want the API to silently fail to return mergeinfo information
> without returning an error, how do you expect the command line to
> figure out that it should error out?
>
>> Maybe that is all you have been proposing, in which
>> case I'd be OK. I just want to use the API from JavaHL and not get an
>> error or perform extra server roundtrips. By the way, distinguishing
>> the reason for the error in JavaHL is not always as easy as it sounds.
>
> I don't see why getting an error is a problem. Look, here is what you do:
>
> static someReturnType mphippardSvnLog(args) {
> try {
> return svnLog(args, true);
> } catch (MergeinfoNotSupportedException e) {
> return svnLog(args, false);
> }
> }
>
> What's so hard about that?
>
> And extra server roundtrips? For ra_local and ra_svn there are no
> extra roundtrips. For DAV RA types, there is at most one extra
> roundtrip per RA session (*not* per ra_get_log call... just one per
> session).
>
> I really do not think this places a burden on you at all.
>
> On the other hand, it would be a big burden for the CLI to have to
> stare into a crystal ball to figure out if the non-error return value
> from the get-log API is really an error!
>
>>>>> Using our capability mechanism would be the cleanest way to implement
>>>>> this, IMHO.
>>>> Someone explain to me why our current --depth feature is acceptable
>>>> then? We are really assuming that people's main concern is not having
>>>> extra files locally as opposed to not transferring them over the wire
>>>> in the first place? Because I'd be using the feature for the latter.
>>> Because in fact the back-compat doesn't always send all the gigs; the
>>> following completes in ~no time:
>> So you are saying the behavior is unpredictable (from the user's perspective)?
>
> Once the bugs are ironed out (specifically, one particular task I have
> in mind with ambient depth), the "end result" behavior will be
> predictable. Timing... well, I sure hope it will be predictable; it's
> kind of complex now, and I think it could be otherwise.
>
> But what you're asking for is to make the *result* of the operation
> unpredictable.
>
> Let me reiterate: as currently implemented on trunk, mergeinfo props
> will start leaking into 1.4 repositories! And "svn merge" will work
> to some degree! So people will expect "svn log -g" to either work or
> make it clear that it's not working; it is no good for it to silently
> mimic the no-merge-info case.
I think Dave and I are trying to convey the same thing. (And he's a
bit better at it than I. :)
-Hyrum
Received on Fri Oct 19 20:53:00 2007