On Tue, Feb 02, 2010 at 09:12:42PM +0100, Bert Huijben wrote:
> Yes..
>
> It can also skip libsvn_client and use libsvn_wc or (for what it's worth)
> edit the entries file directly, but that is not the point here..
Heh.
> We have a
> versioning policy on our api and hundreds of existing libsvn_client api
> users.
>
> An application compiled against Subversion 1.0 should still work when the
> library it is linked to is upgraded to 1.7.0... We expect the same for apr
> and all the libraries we use.
OK, fair point. Even if the behaviour wasn't intended, we have to
live with it now, and keep providing it.
> If you want to break these users we have to go to Subversion 2.0.
>
> I know about 3 documented cases where we had to break compatibility for
> specific corner cases with libsvn_wc, but if possible we try to avoid
> breaking existing public apis at all cost.
>
> In this libsvn_client_addX() case it would be adding an extra boolean to
> pass to the new svn_client_addX() function... And passing the right value
> from the wrapper in deprecated.c.
Right, no problem. So we add svn_client_add5, with boolean
'no_global_ignores' and 'no_svn_ignores' (better name anyone?).
The old API would be interpreted as always passing no_svn_ignores = FALSE,
and setting no_global_ignores based on svn_client_add4's no_ignore
parameter. Would that be OK?
Stefan
Received on 2010-02-02 21:21:13 CET