2006/1/19, John Duprey <john.duprey@gmail.com>:
> A number of you have asked if I ever resolved the subversion
> permission problem as I reported it here:
> http://svn.haxx.se/dev/archive-2005-09/0277.shtml
>
> After trying several versions of Apache and Subversion (from both RPM
> and source), I resorted to a complete OS upgrade. Our admin upgraded
> from RHEL3 to RHEL4, updated the server's bios, and I reinstalled
> subversion and Apache from stock RHEL4 RPMS. Now everything works
> fine.
>
> After many many many months of trying to figure out what was wrong,
> this shot in the dark appears to have fixed things. Our subversion
> repository has been stable since we did this.
>
> I wish I could have identified the problem. I wasn't the only person
> with the problem ( several people contacted me with the exact same
> problem wondering if I had fixed it ). The problem did seem specific
> to a version of Linux and one guy was using Solaris, I believe.
Hello all,
I answer to this old mail because I was facing the same bug and I
found what was wrong.
Actually, in my case, this is neither a subversion nor an apache bug
but a php one. A php script was setting an umask without execution
rights (0111) and due to this bug, the apache process kept this umask
and when a subversion commit request tried to create a directory it
was unusable (0111 umask -> no execution rights on created files).
This problem was solved by adding a <?php umask(0022); ?> script in
auto_append_file directive of php.ini.
It seems that this bug will be fixed in next php5.1 release:
http://bugs.php.net/bug.php?id=36630
I hope this message could help someone thanks to mailing list archives!
-- Manuel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Mar 20 11:39:52 2006