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

RE: Windows build severly broken due to read-only issues...

From: Jay Freeman \(saurik\) <saurik_at_saurik.com>
Date: 2002-02-10 23:48:53 CET

Philip:

OK, is there any complaint about implementing a function (for now let's
call it svn_io_set_file_write_also()...) that, given a file, removes the
read-only flag using the implementation of apr_file_attrs_set() I
provided the APR people (wonder how long it will be before someone looks
at it...). Then, we call that in close_adm_file() before
apr_file_rename()? If not, when the Subversion repository starts
working again (I'm getting the REPORT status 500 error, which makes it
difficult to test anything, hehe), I'll write the required changes. I
think that will be sufficient (if not optimal).

*searches through back archives for this thread Philip mentions*

OK, I take it that means I'd be completing this little back-and-forth:

=======================================================================
Greg Stein <gstein@lyra.org> writes:

> (btw, for completeness, we'd also want ways to turn off readonly and
> to the executable state)

Agreed, it's just I have much less interest in writing those :-)

-- 
Philip
=======================================================================
*debates making this a reply to the other thread*  *decides against that
as it may not have as strong an association with this thread*
I agree with the previous comments by Branko and Karl from the Issue
#532 thread that more thought needs to go into how this interface should
be designed, however. 
Sincerely,
Jay Freeman (saurik)
saurik@saurik.com
-----Original Message-----
From: Philip Martin [mailto:philip@codematters.co.uk] 
Sent: Sunday, February 10, 2002 3:57 PM
To: dev@subversion.tigris.org
Subject: Re: Windows build severly broken due to read-only issues...
...
Expecting Unix developers to provide Win32 support just by thinking
about it is not going to work. We need input from Win32 developers.
Consider the read-only problem (which prompted the sermon) this was
first raised last year. Since then there has been no Win32 code
proposed to provide it.  Not a single line. We had another discussion
last month, and the Win32 issue was raised again. I asked for a
possible Win32 interface (not an implementation, just an interface)
but nothing appeared. I asked for a description of the Win32
filesystem behaviour, still nothing. So in the absence of any other
input I proposed an interface, nobody said it was not suitable. In
fact, the comment I got was "this seems the way to go".
Now it is quite possible that the interface won't work on Win32. I
don't know, I'm not a Win32 developer. Perhaps the interface is OK and
it's the application code that needs to change, again it needs a Win32
person to point out the problems. Even better would be to provide a
patch, but describing the problem will do. If a problem is identified
I will try to fix it, but references to "sheer sloppy programming" do
not encourage me. The changes in question did not come out of the
blue, they were posted to the list precisely because I suspected that
there could be platform issues.
Within days of my starting to use apr_file_attrs_set an APR Win32
patch appears, so there are Win32 developers interested in Subversion.
I guess that Subversion currently has more developers using Unix than
Win32. I don't know how to encourage people with Win32 know-how to
contribute, but I wish they would.  Until they do Win32 support is
inevitably going to be a second class citizen. I don't like that, I
want Win32 support (and OS X support, 64-bit support, etc.)  However
it won't just happen, it requires appropriate developer interest.
-- 
Philip
---------------------------------------------------------------------
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:37:06 2006

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

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