Quoting Greg Stein <gstein@lyra.org>:
> On Tue, Jun 25, 2002 at 10:08:14PM +0200, Martijn Boekhorst wrote:
> >...
> > Doesn't it make more sense for a win32 version to use the \ path
> convention and
>
> Nope. You're talking about Subversion paths, not Win32 paths. Subversion
> defines "/" for separators for all paths (files, repository, URLs).
>
> > perhaps layer/wrap these things with either macros or stubs? Using
> MAX_PATH as
> > a constant we can allocate one / thread and use thread local storage
> (related
> > question, are the client libs thread-safe?), then, a macro could be
> included
> > for windows clients to convert these and wrap the original call.
>
> That would break as soon as one function called another. They would compete
> for the per-thread buffer.
If one function calls another they wouldn't need the macro prefixes. (I mean,
also from a performance perspective). libsvn* wouldn't use this internally,
it's merely a boundary interface. The only problem I'd see is that special care
is needed for functions with multiple paths.
>
> > Eg. if I may be nasty :
> > #define svn_wc_check_wc(path, is_wc, pool)\
> > svn_wc_check_wc(PATH_LOCAL_TO_SVN(path), is_wc, pool);
>
> Nope. If a path is translated on its way into, say, libsvn_client, then we
> shouldn't continue translating the thing every time we pass it to a WC
> function.
Agree. Boundary, like above. Continuing the translation is a genuinely bad
idea. You're absolutely right.
> The simple design point is that Subversion (internally) uses a particular
> separator for all paths. Client applications need to transform from the
> local/native style to the SVN style when calling the libraries.
yes... I "voluntarily contributed my thoughts" on that in the other thread on
that so won't comment on it here. Unfortunately, the pain is not in
understanding the vision, the pain is in agreeing with it :-) (eg. "fopen()"
doesn't require me to first translate to clibian semantics (I know, flame-
food)).
Cheers, Martijn.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 25 22:50:30 2002