[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: need help setting up svn+ssh://

From: <junkio_at_cox.net>
Date: 2003-08-22 18:53:43 CEST

>>>>> "BCS" == Ben Collins-Sussman <sussman@collab.net> writes:

>> If so maybe calling umask(2) directly at the beginning of
>> svnserve binary, instead of shipping a wrapper, would be
>> cleaner. Better yet, do it with a command line switch perhaps,
>> so that situations that need it (e.g. svn+ssh) can turn it on?

BCS> Remember that we're using APR as our portability layer. umask() is a
BCS> Unix call, and I don't think there's any equivalent APR call that will
BCS> work on Win32.

I understand that trying to stick to APR is a worthy goal to
push the platform specific issues out of the main project, but
this may be sometimes inpractical, given that APR does not yet
cover all the platform specific issues. There are "#if[n]def
SVN_WIN32" sprinkled in places like libsvn_ra_local/split_url.c,
libsvn_subr/cmdline.c, libsvn_subr/io.c among other places
already, and I do not see much harm to do something like below
in an include file (IMHO #ifdef in include files are cleaner
than in C files):

    /* I understand Win32 does not have a concept of masking the
     * permission bits, so "wide open" is returned as "the
     * previous mask" here.
     */
    #ifdef SVN_WIN32
    #define umask(ignored) 0777 /* ignored */
    #endif

Checking this more explicitly by adding an autoconf check to
define HAS_UMASK to configure.in, and using that symbol instead
of SVN_WIN32 would be even cleaner. But I do not know Win32
environment well enough that its shell can even run configure
script, so I am just speculating here :-).

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 22 18:54:45 2003

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.