Thanks for your answer from your Ferrari.
We’ve considered using the http protocol locally on the unix machine hosting subversion, but then we either have to always type in our password (we’re using ldap verification) which is annoying, or store the password unencrypted locally in the .subversion/auth directory.
Our problem stems from the http process. When an import or commit is done via http, the dav directory in the repository folder becomes 775 (drwxrwxr-x) but the owner and group is daemon, not the original svn group the repository was created with, so no user in the svn group can thereafter write to the repository.
From: David Weintraub [mailto:qazwart_at_gmail.com]
Sent: Monday, November 01, 2010 9:36 AM
To: Polder, Matthew J
Subject: EXTERNAL: Re: write permission issues with repository hosting
On Oct 29, 2010, at 11:41 AM, "Polder, Matthew J" <matthew.j.polder_at_lmco.com<mailto:matthew.j.polder_at_lmco.com>> wrote:
We’re running Subversion 1.6.12 on a Solaris 10 machine and hosting repositories on it. Users can create and use repositories via svnadmin and svn locally on the Solaris machine via file:///<file:///\\>, or they can check in and out via TortoiseSVN 1.6.8 on their PC via the http:///<http://> protocol, with LDAP verification.
It's very simple. All files in the repository must be read/writeable to the user who is running the server side process. For the file:/// protocol, it's the user doing the checkout. For svn://,it's the user who is running svnserve. For http://, it's the user running httpd.
The files don't have to be owned by the user. For example, the user might be a member of a group with read/write access. However, when a new revision is written, the new revision will be owned by the user running the server process.
Normally, you don't use the file:/// protocol except for private repositories. Otherwise, all users can directly manipulate the source repository itself. In fact, I never use file:/// even on my private repository. It's easy enough to run svnserve on my machine.
Have the svnserve and httpd processes owned by the same user and drop file:/// access. Then chown the files to that user and set permissions on all files to 664.
Sent from my iPhone while riding in my Ferrari. (Jealous?)
Received on 2010-11-01 14:53:32 CET