David,

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.

thanks,
matthew

From: David Weintraub [mailto:qazw...@gmail.com]
Sent: Monday, November 01, 2010 9:36 AM
To: Polder, Matthew J
Cc: users@subversion.apache.org
Subject: EXTERNAL: Re: write permission issues with repository hosting

On Oct 29, 2010, at 11:41 AM, "Polder, Matthew J" 
<matthew.j.pol...@lmco.com<mailto:matthew.j.pol...@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.

--
David Weintraub
da...@weintraub.name<mailto:da...@weintraub.name>
Sent from my iPhone while riding in my Ferrari. (Jealous?)

Reply via email to