Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>If you have more than one developer accessing the repository through the <code>file://</code> protocol, you may want to look into setting up a Subversion server (using <code>svnserve</code> or Apache). With that solution, the server itself is responsible for all access and permissions on the repository files, and you won't run into this problem.</p> <p>From the <a href="http://svnbook.red-bean.com/en/1.5/svn.serverconfig.choosing.html#svn.serverconfig.choosing.recommendations" rel="nofollow noreferrer">SVN Book</a>:</p> <blockquote> <ul> <li>Do <em>not</em> be seduced by the simple idea of having all of your users access a repository directly via <code>file://</code> URLs. Even if the repository is readily available to everyone via a network share, this is a bad idea. It removes any layers of protection between the users and the repository: users can accidentally (or intentionally) corrupt the repository database, it becomes hard to take the repository offline for inspection or upgrade, and it can lead to a mess of file permission problems (see <a href="http://svnbook.red-bean.com/en/1.5/svn.serverconfig.multimethod.html" rel="nofollow noreferrer">the section called “Supporting Multiple Repository Access Methods”</a>). Note that this is also one of the reasons we warn against accessing repositories via <code>svn+ssh://</code> URLs—from a security standpoint, it's effectively the same as local users accessing via <code>file://</code>, and it can entail all the same problems if the administrator isn't careful.</li> </ul> </blockquote>
 

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