Checkout SVN repository from a network

Question

I asked a similar question before How to update TortoiseSVN over the network? . At that time I was using a VM copy of the server, and the solution I listed worked. This time I am using the actual server and I have trouble checkout out my repository.

Unable to open an ra_local session to URL 
Unable to open repository 'file://REMOTE-PC/repositories/MyApps/trunk/App1' 
Can't open file '\\REMOTE-PC\repositories\MyApps\trunk\App1\format': Logon 
failure: unknown user name or bad password.

My questions are

1. Do I need special permission on the folder on the server so I can successfully checkout the repository?

2. The documentation here points out which protocol to use where? I was using this before on VM which worked

   file://REMOTE-PC/repositories/MyApps/trunk/App1

What should I be using?

+------------+--------------------------------------------------------------+
| file:///   | Direct repository access (on local disk)                     |
| http://    | Access via WebDAV protocol to Subversion-aware Apache server |
| https://   | Same as http://, but with SSL encryption.                    |
| svn://     | Access via custom protocol to an svnserve server             |
| svn+ssh:// | Same as svn://, but through an SSH tunnel.                   |
+------------+--------------------------------------------------------------+

What it worked before and does not work now? Please address both the questions.

I also want to mention, If I want to access my PC (where repository are) from server (I am using remote desktop), I have to enter username and password. Do I have to supply these in SVN command?

Answer 1

You should never use the file:// protocol. Never, never, never. Well, there are times when it can be used, but it should only be if all the following are true:

• You are the only one using the repository.
• The repository is sitting on your system.
• You are trying Subversion out.

If your repository sits on a remote system. Do not use file:// . If this is a public repository, you do not use file:// . The svnserve Subversion server process is extremely easy to setup and use. And, it's fast, and it avoids all the problems and errors associated with accessing the repository directly. In fact, on my private repository that sits on my system, I use svnserve .

---

There are at least a dozen errors that could crop up to cause the problems you point to. There are permissions needed for the server, on modern Windows system, there could be UAC issues even if you're logged in as an administrator. It simply is asking for trouble.

Take a look at the documentation for setting up the svnserve . The biggest issue you will run into is making sure that your IT department isn't blocking port 3690.

Run the svnserve process on the remote server and make sure that the server process has complete ownership and all permission on all the files in the repository.

There are a couple of gotchas about the svnserve process that doesn't allow it to run out of the box:

• Edit the conf/svnserve.conf file : This file is pretty good by default. However, the default password file is commented out. Remove the # you see in front of the line password-db = passed . I'm not sure why this isn't the default. You can also set the name of the realm while you're at it. That's not necessary.

• Edit the passwd file : You need to set the user name and password for each user. Just follow the example.

And, then run svnserve and now you can access your repository via:

$ svn ls svn://REMOTE-PC/MyApps/trunk/App1

This is easy to do (the whole thing can be setup in minutes) and will eliminate all of your problems.

Answer 2

With Subversion, your libraries have strict requirements on the files being manipulated to store "the repository". SMB services / Windows shares / Samba doesn't meet those requirements.

You should never hide the network from subversion by using the file:// protocol across a network share. This means that network failures and outages don't trigger subversion's awareness that a change might not be properly stored. Depending on the change and circumstance, this can have really bad effects on your repository.

If you are using a remote repository, use one of the network-aware protocols. They have the proper code to detect and capture network outages and will not be confused into mis-reporting something was saved in the repository.

Answer 3

检查此路径的读/写权限：

\\REMOTE-PC\repositories\MyApps\trunk\App1