Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>If you're using the <code>svn://</code> protocol, the read/write permissions must be for the user who is running the <code>svnserve</code> process. In fact, this is exactly why you should not use the <code>file://</code> protocol when you have multiple users...</p> <p>When you use <code>svn://</code> as your protocol, you're asking the <code>svnserve</code> process to do the reading and writing to your Subversion repository. Thus, you as the user don't need actual read/write permission.</p> <p>In fact, you don't want anyone other than the <code>svnserve</code> process to be able to touch your repository files directly. The standard setup is to have the files in your Subversion repository only accessible to the user that's running the process that's you're Subversion server process: Whether it's <code>httpd</code> or <code>svnserve</code>.</p> <p>To solve your problem, make sure that the user that's running <code>svnserve</code> command owns the files in your Subversion repository directory tree. Make sure all the files and directories are set to <code>rwx------</code> or <code>rwxr-xr-x</code>. That way, no one but the <code>svnserve</code> process can touch the files.</p> <p>So, how do you specify security? In the Subversion repository directory, there's a directory called <code>conf</code>. The easiest way is to configure a file called <code>svnserve.conf</code>under this directory. There are three sections you're interested in:</p> <ul> <li><p>About line 11, there are two lines <code># anon-access = read</code> and <code># auth-access = read-write</code>. You can remove the <code>#</code> at the beginning of the line to enable these two parameters. <code>anon-access</code> sets what type of access you have when you don't log in. Default is <em>read</em>. You probably want to change this to <em>none</em>. The other is the type of access you have when you log in. You want to keep the default which is <em>read-write</em>. </p></li> <li><p>About line 20 in the <code>conf/svnserve.conf</code> file, there's a line <code># password-db = passed</code>. In line 11, you specified what access users who log in have. Now, you're specifying what file contains the logins and passwords. Remove the <code>#</code> from the beginning of this line to specify that the <code>conf/passwd</code> file has your user names and passwords. There's a sample <code>passwd</code> file in that directory. <strong>NOTE</strong>: Make sure that this file has the permission <code>rw-------</code> on it. You don't want anyone to be able to open it and see the passwords!</p></li> <li><p>Normally, that's all you're interested in. Most sites say anyone who can log in should be able to make changes. After all, if someone makes a mess, you can always undo it. However, if you want to be stricter on who can change what files, you want to loo around line #27 in the <code>conf/svnserve.conf</code> file. This looks like <code># authz-db = authz</code>. Again remove the <code>#</code> from the beginning. In the <code>conf</code> directory, there's a sample <code>authz</code> file that shows you how to setup who has read or read-write access to particular sections of the repository. I highly recommend that you think twice, maybe three times before doing this. Otherwise, you will be creating a lot of work for yourself and making all of your developers hate you. It's not unusual for developers to be pulled from one project to another. If you've tightly locked down projects so only certain developers can write to certain projects, you'll be changing this file every time a developer switches projects, and developers will have to wait for you before they can do their work. Light touch. Light touch.</p></li> </ul>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload