On 10/19/07, David Glasser <glasser@davidglasser.net> wrote:
> 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.
I am saying it would be impossible or even hard to code this as you
suggest. I am saying if we think this is an error condition then that
creates a UI problem (for me). Somewhere the user has told me they
want to see merged revisions, for certain repositories I cannot show
them. Throwing an error is going to really suck, and it sounds like
you think showing the merged revision column with no data is worse.
> > 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?
The command line could check capabilities, similar to what Stefan asked.
> > 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?
Aside from the fact that we do not throw nice exceptions like that,
nothing. I am talking about the UI not the code. As for the code, I
will probably have to do something stupid and error prone like match a
string in an exception message.
> 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.
How quickly does the first call fail? Does it need credentials to get
the capabilities?
> 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!
The CLI could check the capabilities or it could indicate to the API
that it wants it to fail.
> 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.
In the case of --depth you are defining the result as what shows up on
disk at the end. I define it to include the time it takes to
complete. Are you saying that --depth now works with older servers
exactly the same as it does with 1.5? No extra files are ever sent
across the wire?
> 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.
Iterate all you want, I just do not agree with you. Why aren't you
calling for changes to merge itself? Why should merge tracking work
"to some degree" with a pre-1.5 server?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 19 20:55:36 2007