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
