Sean
Sean

Reputation: 62472

TortoiseSVN can't connect to SlikSVN Subversion server

I've created a SubVersion server on one of the machines in my workgroup. From my development box I'm able to access the repository and check in/out files without any problem.

I've just installed TortoiseSVN and no matter what I do it won't connect to the repository on the server. I get the infamous error "No connection could be made because the target machine actively refused it".

Does anyone have any ideas why this might be..? As far as I know, the tortoise shell extension is running under my user credentials. It seems strange that the SVN command line tools work correctly, but not Tortoise.

Both machines are running Vista

NOTE: In both cases I'm using the svn protocol to connect

Finally, I've fixed it...! The problem seems to be with the Subversion package I downloaded. I downloaded the latest version of SlikSVN (1.5.5) and installed it on my client and server. It seems TortoiseSVN doesn't like this build/version. I just uninstalled SlickSVN on both machines and grabbed the latest version from CollabNet and now everything works as expected!

Upvotes: 5

Views: 9866

Answers (8)

Ronald
Ronald

Reputation: 61

Just add --listen-host 0.0.0.0 to your SVN service command. The problem is that you are creating the service listening to IPv6 and you are trying to access it using IPv4. Look at this:

http://www.renaissance-design.net/code/installing-and-configuring-svnserve-and-tortoisesvn-on-windows/

Upvotes: 6

George
George

Reputation: 1

I re-ran the command svnserve --daemon --root D:\Subversion\Repo, and this resolved this error.

This error came up suddenly. We were working fine one minute, and the next we saw this error. Not sure why.

Upvotes: 0

Steven Robbins
Steven Robbins

Reputation: 26599

Might be worth checking that Tortoise hasn't picked up on a proxy setting (Network settings in Tortoise config). From the same screen you can open the SVN server file and see if there's anything weird going on in there.

Upvotes: 1

Bert Huijben
Bert Huijben

Reputation: 19612

The Slik Subversion Client is IPv6 and IPv4 enabled, so if your system says it prefers IPv6. With the --listen-host argument you can choose how it should listen.

Upvotes: 0

manovich
manovich

Reputation:

I had the same problem with SlickSVN 1.5.5. But in my case it was local subversion server running in deamon mode. CollabNet package works fine with the same configuration.

Upvotes: 0

Sean
Sean

Reputation: 62472

Finally, I've fixed it...!

The problem seems to be with the Subversion package I downloaded. I downloaded the latest version of SlikSVN (1.5.5) and installed it on my client and server. It seems TortoiseSVN doesn't like this build/version. I just uninstalled SlickSVN on both machines and grabbed the latest version from CollabNet and now everything works as expected!

Upvotes: 2

Stefan
Stefan

Reputation: 43575

Please check the following:

  • is your firewall configured to let traffic through (port 3690, by default, or any other port you might have svnserve configured to run on). Check firewalls both on your client machine and on the machine you run svnserve.
  • many virus scanners also interfere with 'unusual' network ports
  • the default host svnserve is listening on is 'localhost', which means you won't be able to connect to it from another machine. Did you start svnserve with the '--listen-host serverhostname' param?

Edit: if you're using the collab.net server, you have to start the service manually:

net start svnserve

Also this might help: http://subversion.open.collab.net/articles/svnserve-service.htm

Upvotes: 1

Mihai Limbășan
Mihai Limbășan

Reputation: 67506

What protocol are you using to access the server-side repository? If it's not a file:// protocol, have you confirmed that the corresponding server is actually running? Try to connect to it manually, for example by running

telnet target.machine.ip.address target_port

(of course, replacing target.machine.ip.address by the actual IP address and target_port by the numeric server port). If that port is open, the screen will clear, otherwise telnet will hang for a while then complain.

If it works using the IP address and not the machine's name, you have a problem in name resolution (check your DNS and/or WINS settings.)

Upvotes: 0

Related Questions