On 10/19/07, David Glasser <glasser@davidglasser.net> wrote:
> > 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*.
I am not saying I cannot handle this or that JavaHL can't. By the way
the only issue with the exceptions is that they are all thrown as the
same type of exception so you have to do something to distinguish the
reason.
Where we disagree is that I do not understand why we are elevating
this one scenario (that I happen to think is fairly benign) to this
special status. Other than lock, what commands have ever failed
because of the server version? Why is this so special? Let me give
some examples:
1) You could upgrade everything to 1.5, be using merge tracking on a
project for months, and anyone can come along and perform and commit a
merge using an older client (which will not create the merge tracking
information). We do not seem to care.
2) Similarly, someone can create a branch with an older client and
not have their mergeinfo generated.
3) Users can do --depth checkouts and have a lot more data sent to
the client then they were expecting. As Stefan pointed out we also
experience this with log --limit and older servers.
4) As you pointed out someone can use a 1.5 client with a 1.4 server
and get semi merge tracking features and not realize it does not
completely work.
There are probably others. I just do not understand why this
situation is so special. I think numbers 1 and 4 above are far worse.
Do you have emails queued up for those issues?
Maybe you have really minimized #3, but I still think that is a bigger
problem than log -g.
> 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.
They are useful, just not as easy as if there were more unique
exceptions, or if every exception carried an error code. Some of them
do.
> > 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).
But I assume it is all done in the handshaking? Not after waiting for
the server to start processing the command?
> 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.
I am not sure this is as significant. If someone wants to implement
merge tracking, really needs it, they are making a huge mistake if
they are not going to do some client inventory. Plus people can
update the repository to a 1.5 specific format if they choose to.
Anyway, I do not wish to give the impression that I intend to try to
exercise a veto. I just do not agree with the importance here and
don't think producing an error is warranted here.
--
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 22:40:48 2007