John Szakmeister <john@szakmeister.net> writes:
> I actually thought of that this morning and had a paragraph in the
> email about it. I think the best answer to this problem is to fix
> svn_client_blame() which is why I proposed that as a solution (every
> other user of svn_client_blame() is going to have to implement the
> same logic otherwise). But, I also though that this could fit into
> 1.1. I have to admit I'm still a little confused about the API
> compatibility/deprecation stuff. I read the following paragraph, and
> told myself that we aren't changing the signature at all and old
> clients would still function with the new restrictions (actually, it's
> less restrictive :-).
>
> 2) Upgrading to a new minor release in the same major line may
> cause new APIs to appear, but not remove any APIs. Any code
> written to the old minor number will work with any later minor
> number in that line. However, downgrading afterwards may not
> work, if new code has been written that takes advantage of the
> new APIs.
We're not changing the signature, but we'd be very clearly changing
the interface promise. The current API *promises* an error if you
pass unspecified revision. Clients might be relying on that behavior.
We can change a function's behavior to fix a bug. But making it
behave the opposite to its documentation is not fixing a bug, it's a
true interface change (though not a signature change).
> If changing svn_client_blame() doesn't get us into 1.1, then I'd say
> you and C. Mike are right, we just fix the inputs in the command line
> client and wait until 2.0 to fix the API.
Sounds good.
> Yeah, that's too much for such a minor change. We should just file an
> issue for a 2.0 change to the API, and take care of it then. I can do
> that if no one objects to it.
Thank you.
> S.Ramaswamy, did you want to take a stab at fixing this in the
> command-line client? Basically you need to choose the end revision to
> be HEAD if the target is a URL, and BASE if it's a working copy path.
> You can use svn_path_is_url() to make that determination.
Agreed. Ram, just ask if want more details, happy to oblige...
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 17 00:17:01 2004