You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Martijn Boekhorst <su...@boekhorst.net> on 2002/06/25 20:08:14 UTC
Issues 584 & 603 -- / vs. \
This is really really really akward to code - and I find myself making _alloca
macros to get around the issues.
Doesn't it make more sense for a win32 version to use the \ path convention and
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.
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);
at the bottom of the file - or better - in a seperate include file (keeping the
original relatively muck-free), included conditionally at the bottom of the svn
include file (I don't know - making it up).
Just thinking out loud here and these are probably silly thoughts, but using
forward slashes on a win32 platform is really quite 'strange', regardless of
URL formatting which needs translation anyway; and in addition represents a
barrier for entry since I couldn't find it documented anywhere (which could be
my failure to look for it ofcourse).
To-do or Too-bad?
Cheers, Martijn.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issues 584 & 603 -- / vs. \
Posted by Branko Čibej <br...@xbc.nu>.
Martijn Boekhorst wrote:
>Quoting =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <br...@xbc.nu>:
>
>
>
>>Martijn Boekhorst wrote:
>>
>>
>>>Quoting =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <br...@xbc.nu>:
>>>
>>>
>>>>Many programs on Windows accept forward slashes today, and the MS C
>>>>runtime groks them and converts accordingly. So does APR, for that
>>>>
>>>>
>>matter.
>>
>>
>>>So shouldn't subversion?
>>>
>>>
>>No, it should not. The Subversion libraries are not a general-purpose
>>portability layer, unlike the C library. The client program knows best
>>when and how to convert or construct the paths so that they conform to
>>the SVN lib requirements, so we're going to leave that work to the client.
>>
>>
>
>Subversion is not general purpose but I think/hope the client libraries qualify
>as portable - if only from an api design perspective. Currently the path part
>of the api is designed with subversion development in mind, not with api users
>in mind. If everyone who calls the API on a non-unix platform (MacOs/win) has
>to write code so the API understands the platform it is inhabiting, then there
>is an "oppertunity for improvement" with the API as, for that particular
>platform, the wrong standards are imposed.
>
Well, we will have helper functions in libsvn_subr that'll handle those
conversions for us, and the (portable) command-line client will use them.
Basically, we have two problems:
* The Subversion libraries call one another, as well as being called
from the client. If we push the conversions to the level of the
library interface, then we still have to maintain a set of APIs
that don't do the conversion, so that inter-library calls can use
them.
* Client code is more than just converting user input into calls to
libsvn_client. Typically, you'll have several calls to ..._wc and
..._subr before and after. The client writer will know best where
the conversion should be done.
So, basically, it's a question of efficiency -- both the runtime
efficiency of not converting every path more than once (if that
matters), and code complexity, which is more important.
>>We discussed this issue to death several times ago. Please, search the
>>list archives, read those discussions first.
>>
>>
>I'm resurrecting the topic quite consciously since from now 'till this problem
>is grabbed by the horns (possibly never), most client writers will probably
>raise the issue at one point or another (*envisions svn world with many
>clients*).
>
I understand your concern, but I really can't see a better solution than
the one proposed (ATM). I expect that the revamped command-line client
will be a good example for other client writers.
--
Brane Čibej <br...@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
Re: Issues 584 & 603 -- / vs. \
Posted by Martijn Boekhorst <su...@boekhorst.net>.
Quoting =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <br...@xbc.nu>:
> Martijn Boekhorst wrote:
> >Quoting =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <br...@xbc.nu>:
> >>Many programs on Windows accept forward slashes today, and the MS C
> >>runtime groks them and converts accordingly. So does APR, for that
> matter.
> >So shouldn't subversion?
> No, it should not. The Subversion libraries are not a general-purpose
> portability layer, unlike the C library. The client program knows best
> when and how to convert or construct the paths so that they conform to
> the SVN lib requirements, so we're going to leave that work to the client.
Subversion is not general purpose but I think/hope the client libraries qualify
as portable - if only from an api design perspective. Currently the path part
of the api is designed with subversion development in mind, not with api users
in mind. If everyone who calls the API on a non-unix platform (MacOs/win) has
to write code so the API understands the platform it is inhabiting, then there
is an "oppertunity for improvement" with the API as, for that particular
platform, the wrong standards are imposed.
> We discussed this issue to death several times ago. Please, search the
> list archives, read those discussions first.
I'm resurrecting the topic quite consciously since from now 'till this problem
is grabbed by the horns (possibly never), most client writers will probably
raise the issue at one point or another (*envisions svn world with many
clients*).
However, since enthusiasm to take this on appears to be somewhat lacking, I'll
probably be implementing the TLS wrapper-based boundary approach (with Greg's
comments in mind) for the functions I happen to need, remaining relatively
indifferent about re-use potential.
Cheers, Martijn.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issues 584 & 603 -- / vs. \
Posted by Branko Čibej <br...@xbc.nu>.
Martijn Boekhorst wrote:
>Quoting =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <br...@xbc.nu>:
>
>
>>Many programs on Windows accept forward slashes today, and the MS C
>>runtime groks them and converts accordingly. So does APR, for that matter.
>>
>>
>
>So shouldn't subversion?
>
>
No, it should not. The Subversion libraries are not a general-purpose
portability layer, unlike the C library. The client program knows best
when and how to convert or construct the paths so that they conform to
the SVN lib requirements, so we're going to leave that work to the client.
We discussed this issue to death several times ago. Please, search the
list archives, read those discussions first.
--
Brane Čibej <br...@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
Re: Issues 584 & 603 -- / vs. \
Posted by Martijn Boekhorst <su...@boekhorst.net>.
Quoting =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <br...@xbc.nu>:
> Martijn Boekhorst wrote:
>
> >This is really really really akward to code - and I find myself making
> _alloca
> >macros to get around the issues.
> >
> >Doesn't it make more sense for a win32 version to use the \ path
> convention and
> >perhaps layer/wrap these things with either macros or stubs?
> >
> We already tried handling the different separator styles all through the
> code. It doesn't work out, there were more bugs cause by trying to do
> that than I can count. Ripping that crud out of the libraries was one of
> the best decisions ever made.
>
> >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.
> >
> >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);
> >
> >at the bottom of the file - or better - in a seperate include file
> (keeping the
> >original relatively muck-free), included conditionally at the bottom of
> the svn
> >include file (I don't know - making it up).
> >
> Doesn't make sense. Remember, the libraries offer a _programming_
> interface, so requiring forward slashes there is quite O.K. Especially
> if we provide conversion functions for clients to use, which we will.
Yes, agree completely, but only on programming interface, not the forward
slashes bit. See below.
> >Just thinking out loud here and these are probably silly thoughts, but
> using
> >forward slashes on a win32 platform is really quite 'strange',
> >
> Many programs on Windows accept forward slashes today, and the MS C
> runtime groks them and converts accordingly. So does APR, for that matter.
So shouldn't subversion?
Cheers, Martijn.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issues 584 & 603 -- / vs. \
Posted by Branko Čibej <br...@xbc.nu>.
Martijn Boekhorst wrote:
>This is really really really akward to code - and I find myself making _alloca
>macros to get around the issues.
>
>Doesn't it make more sense for a win32 version to use the \ path convention and
>perhaps layer/wrap these things with either macros or stubs?
>
We already tried handling the different separator styles all through the
code. It doesn't work out, there were more bugs cause by trying to do
that than I can count. Ripping that crud out of the libraries was one of
the best decisions ever made.
>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.
>
>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);
>
>at the bottom of the file - or better - in a seperate include file (keeping the
>original relatively muck-free), included conditionally at the bottom of the svn
>include file (I don't know - making it up).
>
Doesn't make sense. Remember, the libraries offer a _programming_
interface, so requiring forward slashes there is quite O.K. Especially
if we provide conversion functions for clients to use, which we will.
>Just thinking out loud here and these are probably silly thoughts, but using
>forward slashes on a win32 platform is really quite 'strange',
>
Many programs on Windows accept forward slashes today, and the MS C
runtime groks them and converts accordingly. So does APR, for that matter.
--
Brane Čibej <br...@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
Re: Issues 584 & 603 -- / vs. \
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Martijn, can you start out by stating concisely the problem you're
trying to solve here? I wasn't able to understand that mail much.
You do know that we're *not* asking Win32 users to type forward
slashes in their arguments, right? (It sounds like you do know that,
I just am making sure.)
-Karl
Martijn Boekhorst <su...@boekhorst.net> writes:
> This is really really really akward to code - and I find myself making _alloca
> macros to get around the issues.
>
> Doesn't it make more sense for a win32 version to use the \ path convention and
> 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.
>
> 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);
>
> at the bottom of the file - or better - in a seperate include file (keeping the
> original relatively muck-free), included conditionally at the bottom of the svn
> include file (I don't know - making it up).
>
> Just thinking out loud here and these are probably silly thoughts, but using
> forward slashes on a win32 platform is really quite 'strange', regardless of
> URL formatting which needs translation anyway; and in addition represents a
> barrier for entry since I couldn't find it documented anywhere (which could be
> my failure to look for it ofcourse).
>
> To-do or Too-bad?
>
> Cheers, Martijn.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issues 584 & 603 -- / vs. \
Posted by Martijn Boekhorst <mb...@xs4all.nl>.
Quoting Greg Stein <gs...@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
Re: Issues 584 & 603 -- / vs. \
Posted by Greg Stein <gs...@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.
> 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.
>...
> Just thinking out loud here and these are probably silly thoughts, but using
> forward slashes on a win32 platform is really quite 'strange', regardless of
> URL formatting which needs translation anyway;
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.
> and in addition represents a
> barrier for entry since I couldn't find it documented anywhere (which could be
> my failure to look for it ofcourse).
It isn't documented, but it will be one day.
Ben just detailed the needs for many of the inputs to the SVN libraries.
(although I question what other types of inputs we have, and if we need any
processing on them, too)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org