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.
--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 20:35:30 2007