Tortoise Svn Server Setup Windows 10

[Geoffrey Beird]

Iinstalled tortoise svn on a remote windows 2012 server which is running iis and created a repository using tortoise svn. but i can only access the repository locally using svn://localhost. when i try accessing it remotely with svn://directIP, i get the error "cannot connect to host 'directIP'... ". however the ip address is valid and i can hit it with a web browser. but iis is the server handling all incoming request on the remote windows 2012 server. am thinking windows server is not allowing unauthorized remote access to the server, that is why am unable to access the repository remotely...is there a way i can access my tortoise svn repository remotely while my iis is still running? please i need help!

If you are really able to access the repository at localhost via the svn:// protocol (and not with file:// protocol) this would indicate that a subversion server is already running. In this case it might be a firewall problem and you have to open the svn port 3690 on your Windows server.

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).

The repository is fine. When I go to commit something to the same place with my windows client it works great. The windows client is 1.6.11 and the mac client is 1.6.12 I wouldn't think that would be that big of a deal.

TortoiseSVN is a Subversion client. Whilst it does include the svnserve server, you will need to manually configure that. You may want to have a look at uberSVN, which allows you to configure an Apache Subversion webserver so that you can access your repository via

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.

I currently use Atlassian/BitBucket on a linux server, but use a Windows pc for my code editing etc.. of my cloned branches. Can I use Tortoise Git for windows with my linux repo in bitbucket and if so how do I set it up?

If your code is already on Bitbucket, then you simply click the 'clone' button in the sidebar (the first button under the project icon) to get the clone URL (see the Bitbucket documentation on how to clone a repository for more details). Once you have copied the clone URL, you can give it to Tortoise Git as the 'URL' field (see the TortoiseGit documentation on how to clone a repository for more details)

If your code is already local, then you will need to create a repository in Bitbucket. After that you can go to the TortoiseGit settings to change/set the remote of your local repo to the clone url of the repo you just created and push your code up to Bitbucket.

My initial problem is that TortoiseGit is wants me to configure the path to a Git.exe, which as far as I can tell I don't have since it's hosted on Linux and not windows. It will not let me do anything else until I give it a valid path to the exe.

A little background. We already have a Git repo that we are using on a linux server (Work stations are Windows 7) and have recently purchased Atlassian and migrated the repo to work with Bitbucket. Everything seems to work fine with the exception of getting TortoiseGit integrated due to the path issue mentioned above.

ok, the issue seems to be that we have a git repo using BitBucket on a linux server. We clone our repos into a public share folder on the linux server and work development from there accessing it from Windows 64 bit machines. So... I'm not sure how this will work since we don't have git installed on the local Windows machines. Do we need to install something like SmartGit on the linux server and work that way some how? Or install TortoiseGit on the windows machines and some how tie it into the linux public share cloned repos?

Yes, our team works from public folders on the linux server because we work on a closed network doing embedded development. The team is kind of large so working in a public space allows us access to everyone else cloned repos in case someone is sick or out unexpectedly. Also, we need to be able to link our individual code builds directly to our target hardware for integration and testing. We've found that this doesn't work very well using local Windows machines.

Tortoise Git cannot use the git executable you have on the linux drive. The Tortoise Git client is a Windows program, and as such you need to install the git client locally on your Windows computers; it is a requirement of the program.

Sean, you note that I can set up an svn server and access over svn+ssh. I did that, works well. But: for Windows client (staging, production machines in the cloud) no ssh is available by default. What's the status of https: access for an OpalStack-hosted svn server?

Tortoise for GUI, command-line (my normal mode). More reading led me to setting SVN_SSH environment variable ( -to-use-svnssh-with-tortoise-svn-from-the-command-line) which seems to work. Now spelunking around trying to work out certificates, etc so I don't have to share passwords with the cloud machine. Ugh.

3a8082e126