Tortoisesvn Server Setup

[Oliver Parkes]

Touse TortoiseSVN (or any other Subversion client), you need a place where your repositories are located. You can either store your repositories locally and access them using the file:// protocol or you can place them on a server and access them with the or svn:// protocols. The two server protocols can also be encrypted. You use or svn+ssh://, or you can use svn:// with SASL.

If you are using a public hosting service such as SourceForge or your server has already been setup by someone else then there is nothing else you need to do. Move along to Chapter 4, Daily Use Guide.

If you don't have a server and you work alone, or if you are just evaluating Subversion and TortoiseSVN in isolation, then local repositories are probably your best choice. Just create a repository on your own PC as described earlier in Chapter 3, The Repository. You can skip the rest of this chapter and go directly to Chapter 4, Daily Use Guide to find out how to start using it.

In the early days of Subversion, setting up a server required a good understanding of server configuration and in previous versions of this manual we included detailed descriptions of how to set up a server. Since then things have become easier as there are now several pre-packaged server installers available which guide you through the setup and configuration process. These links are for some of the installers we know about:

To set up a Subversion server on windows there are a number of options available. The easiest option and most performing, but not always the most accessible is by using the svnserve service which is provided in the binaries of

Both solutions are sometimes hard to set up and a number of free and paying solutions exist to easier serve your subversion repositories on windows. Some examples, but definitely not an exhaustive list:

I think you got several things mixed up:

- Visual Source Safe (or VSS) was a version control system by Microsoft (deprecated, and utterly broken IMO)

- Subversion (or SVN) is a widely used version control system (having a client-server architecture, but you can run both on the same machine)

- TortoiseSVN is a Windows client for SVN (having nice features like Integration into Windows explorer with icon overlays)

So if you want to start using SVN, you have to set up a server (should be pretty straightforward, since there's lots of good documentation available) and decide on a client (TortoiseSVN highly recommended if you are using Windows).

1.The existing Repositories is on E:\Repositories, should I make a backup copy? and can we select the existing Repo during the installation? (The existing VisualSVN Server is installed at the default localtion C:\Program Files (x86)\VisualSVN Server

VisualSVN Server 1.6.3 is linked against Subversion 1.5.5 while 2.5.9 comes with Subversion 1.7.9. Note that Subversion 1.7 introduced a lot of user-visible changes both on the client and server sides. So I strongly recommend an administrator to read the Apache Subversion 1.7 Release Notes.

I will soon start working on a project and the source code is on a remote location. However, I have got the source code on my C drive in a folder. I have VisualSVN server and TortoiseSVN client on my machine. I will be controlling the project work with two other people working on the same project. How do I create a repository on Visual SVN from the local folder?

I have Visual SVN setup on a Virtual Machine so I'll try and help as best as I can. I used subversion for a bunch of university projects so I have a pretty good idea of how Visual SVN works. You don't create a repository from a local folder. It's all done through Visual SVN.

Additional Notes: When working on the files, it would be a good idea to use the Get Lock and Release Lock options. However, it would be even better if you set specific working times for each user as someone may forget to release the files.

The weird thing is that when the server is connected through the router I can access the repository through the browser (e.g. :8081/svn/project), but still can't connect through the tortoise repo-browser (the following error message appears: Error running context: The server unexpectedly closed the connection).

You confirmed you could access to the SVN server as :8081/svn/project; can you also confirm your local repo has the same URL? This is because you wrote you used port-forwarding, which implies that the SVN URL in your existing local repo might be different from the "current" SVN URL :8081/svn/project.

As it turns out, my ISP blocked the access to some 'suspicious' protocols (one of the was webdav). don't know why they thought I need that kind of protection and why they didn't let me know it's there... anyway, now everything's back to normal

I ran this command: We run a Subversion hosting service over HTTPS (yes, Subversion still exists!) We are very happy with Let's Encrypt, but right now there are a few customers using TortoiseSVN (a Windows Explorer-integrated Subversion client) who are getting failures to validate the server certificate.

I'm not a Windows user, so I may be making mistakes, but it appears that the ISRG root is in my Windows' trust store. The DST root is also still there. I tried deleting the DST root, and disabling it, but this does not help the problem. The DST root seems to return anyway, so I cannot really delete it.

The good news is you must have a well connected system and it is automatically updating the roots for you.

If you no longer want to trust that cert, then move it into the "Untrusted Certificates" folder.

But that will likely do little to correct this VPN trust failure.

I suspect that the TortoiseSVN bundles some libraries that may need to be updated/patched.

You might find more about that on their site or through other information channels.

For the time being...

Form the menu choices shown in the error message, it seems that you could verify that fingerprint and trust it "permanently" (until the cert renews and fingerprint changes - LOL) to minimize the noise it creates.

I will try to get in contact with the TortoiseSVN developers to see if they have the same problem and hopefully we will find out the root cause of this validation issue. I will update this thread with my findings.

If TortoiseSVN relies on an embedded version of OpenSSL, it may not actually be using the Windows trust stores for certificate validation. There may be a file based trust store in the app's installation folder somewhere that doesn't have the ISRG Root X1 in it.

But I'm guessing you don't have a lot of old Android devices doing version control against your server. You may want to serve the shorter, alternate chain instead which tends to be more compatible with OpenSSL in general. I'm not familiar with acme_tiny.py or whether it supports alternate chains though.

O.K. we found out what the problem was. Apparently OpenSSL uses the Windows Root CA list to validate the chain, but NOT the windows intermediate CA list.

Windows will assemble the chain for you if you have a server certificate, and have the intermediate CA certificate in the Intermediate CA store and the root certificate in the Root CA store.

On the server we have chained server certificate with the intermediate certificate. The server now offers both the server and the intermediate to OpenSSL and OpenSSL is able to verify it using the Root CA certificate in the Root CA store.

I'm not sure whether this helps beyond confirming how Tortoise does cert validation. Their problem was due to the server not serving any chain which is not your current problem. I'd still probably lean towards trying to switch your server to the short chain though.

One server admin resolved the problem by switching to the alternate chain. That leads me to suspect that perhaps TortoiseSVN's bundled OpenSSL is configured in a way to fail. Removing DST should confirm this so I'm still going to play with that.

Copyright 2023 The Apache Software Foundation, Licensed under the Apache License, Version 2.0. Apache, Apache Subversion, and the Apache feather logo are trademarks of The Apache Software Foundation. Subversion and the Apache Subversion logo are registered trademarks of The Apache Software Foundation.

Welcome to subversion.apache.org, the online home of the Apache Subversion software project. Subversion is an open source version control system. Founded in 2000 by CollabNet, Inc., the Subversion project and software have seen incredible success over the past decade. Subversion has enjoyed and continues to enjoy widespread adoption in both the open source arena and the corporate world.

Subversion is developed as a project of the Apache Software Foundation, and as such is part of a rich community of developers and users. We're always in need of individuals with a wide range of skills, and we invite you to participate in the development of Apache Subversion. Here's how to get started.

Subversion exists to be universally recognized and adopted as an open-source, centralized version control system characterized by its reliability as a safe haven for valuable data; the simplicity of its model and usage; and its ability to support the needs of a wide variety of users and projects, from individuals to large-scale enterprise operations.

We are pleased to announce the release of Apache Subversion 1.14.3. This is the most complete Subversion release to date, and we encourage users of Subversion to upgrade as soon as reasonable. Please see the release announcement and the release notes for more information about this release.

The Subversion 1.10.x line is end of life (EOL).It was released on 2018-04-13 and was supported for the last four yearsaccording to the LTS release life-cycle (see How we planreleases). We recommend everyone to update to the current LTS release 1.14.2 as soon as practicallypossible since we've stopped accepting bug reports against 1.10.x and will notmake any more 1.10.x releases. The last 1.10.x release (1.10.8) was madeon 2022-04-12 and is available to anyone who can't update to 1.14.

3a8082e126