On 10/19/07, Mark Phippard <markphip@gmail.com> wrote:
> 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.
If you believe that for your application, if the user has requested
they want to see merged revisions, but the server does not support
that, it should silently pretend that there were no merged revisons...
that's great!
Other applications, such as the command line, might disagree.
Making the API throw an error and the application retry would allow
*both types of applications* to work. *This is an idiom used ALL OVER
Subversion.* This is *normal*. This happens inside your program *all
the time*.
> > > 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.
For the last time: You should implement whatever UI you want!
If you use the wrapper I wrote above instead of a direct API call, it
will work *exactly like the API that you want*.
Now, if your real problem is "JavaHL doesn't convert svn errors into
Exceptions in a useful manner"... well, sure, that's a problem, but I
don't think crippling core svn is the right answer. The right answer
would be fixing JavaHL.
> > 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?
It would be the first thing checked in the log command (probably in
the loader). I'm not sure about credentials; somebody more familiar
with DAV could look at Karl's change.
> > 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.
Checking caps in the individual client is really a rather low-level operation.
The Subversion API is built around being able to deal with errors.
When we are writing C code, we have to write SVN_ERR around *every
single function call* (more or less). We do this so that we can have
a somewhat-usable exception mechanism. Errors are an important part
of the API. If JavaHL can't deal with this fundamental part of our
API, that's a shame.
> > 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?
Those are two different questions. The simplest answer is "no"; if we
could tell old servers to send exactly the right thing then this
wouldn't be a new feature :)
> > 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?
Don't forget: you are conflating server revision and repo revision
again. Yes, in well-designed corporate setups there will be one
server and upgrading the server is a major planned process. But
Subversion also supports things like ad hoc collaboration with a
server stored on NFS and different users using svn+ssh:// to different
machines to access the same repository; different users will end up
using different versions of svnserve to access the same repo without
necessarily making the explicit choice to do so.
--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
Received on Fri Oct 19 21:12:34 2007