On 11/04/2011 10:53 AM, Barry Scott wrote: > > On 3 Nov 2011, at 11:48, C. Michael Pilato wrote: > >> On 11/02/2011 05:42 PM, Barry Scott wrote: >>> I wish that the canonical stuff was inside the svn_client_XXX API calls and >>> not >>> a burdon on callers. To my mind the svn.exe API and the svn_client_XXX >>> should >>> accept the same strings and either operate or return an error. Avoiding the >>> asserts from using svn_client_XXX is the lions share of the work of getting >>> svn binding sane. >> >> Two problems with such a move: >> >> - libsvn_client isn't the only API called from code outside of the >> Subversion core distribution. What does to auto-canonicalization in >> libsvn_client do if passing the same uncanonical path to libsvn_wc will then >> crash? > > Then the logic of the suituation would be that lib_svn_wc needed to > change as well. > >> >> - canonicalizing inside the API means the API must therefore assume that >> input paths are not canonical. That means performing the same >> canonicalization over and over again each time the API is called. That's >> wasteful. Better to ask the highest level of code to make its input conform >> once (we even offer the functions to do so!) and then take advantage of >> known-good input from then on. > > From my point of view svn_client_XXX is the highest level of code I call. > I convert to canonical on every call of svn. Its saves nothing.
It probably saves many duplicate *_canonicalize() calls that the API would cause. You can write a canonicalization wrapper for coding convenience, like you did, or you can choose to handle canonicalization even earlier. > I think it makes using the svn API unnecessarily complex. Actually, the same argument goes for inside the API: assuming non-canonicalized paths makes API development more complex. IMO we need to expect valid data from API callers, for paths as for other args. A possibility would be to provide additional API functions that are simple canonicalization wrappers for the different real API functions -- and that would be code bloat. ~Neels
signature.asc
Description: OpenPGP digital signature
