Bill Tutt wrote:
>>From: Branko Cibej [mailto:brane@xbc.nu]
>>
>[...]
>
>> * Adds two new functions, svn_path_normalize and
>> svn_path_denormalize (he he, love those names) that convert
>> between the local and internal path syntax. These functions
>>
>aren't
>
>> used anywhere yet, but are intended to be used by the client
>> program (*not* libsvn_client) to hammer incoming paths into the
>> internal form and outgoing paths (e.g., those coming from trace
>> editors) into the local form.
>>
>
>Why can't libsvn_client just call the path
>normalization/de-normalization APIs for us? That's where the logic
>should fundamentally go, it's the right layer after all. (That's not to
>say that the command line client might need additional calls to it, but
>why can't the libsvn_client APIs require the path's to be normalized.
>It's not like it's going to significantly impact performance.)
>
We discussed this a while ago on #svn. The upshot was that a) the client
program knows best when to call those functions, and b) not just
libsvn_client, but also libsvn_subr and possibly libsvn_wc would have to
do the conversions if the client didn't, which is definitely overkill.
>I know that if libsvn_client doesn't do the work, the COM layer will.
>The UI code will not have any code that cares about path style
>separation issues (going into the COM layer); it has more important
>things to worry about. I'm not so worried about strings coming back out
>of the COM layer (esp. trace events), but having those calls there as
>well sure would be nice.
>
I suppose the COM layer could be regarded as a client program as far as
Subversion is concerned.
--
Brane �ibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:55 2006