7

We have a server running Fedora 7 that we use as our SVN repository server. New IT policies where I work are mandating that we to a Windows box if we want to allow our server to be on the network.

What are the challenges that must be overcome to make this move? Some of these items may be used to get a policy exception in place.

Jay R.
  • 649
  • 1
  • 10
  • 18

5 Answers5

7

A little check-list:

  • Access method. If you access your SVN server via SSH, you might consider switching to HTTP since it's much more mainstream on Windows.
  • UUID. If you move your repo, just don't forget to make the old one either inaccessible or read-only. Then you can even reuse the same UUID, and enjoy the --relocate option of the switch subcommand on the client for a seamless relocation (no need for a fresh checkout)
  • Apache. You might already have an IIS (or another Web server on the box) so you should change the
  • Database. If you use FSFS as the repository database you can just copy it over. BDB requires a svn dump/load cycle. Think hard if you want to put your database on a network share : only FSFS will work (it's not really recommended though).
  • Users. You have to think about how your users will be authenticated. It may be as simple as copying a htpasswd file over.
  • SVN Version. Just beware that you use the same version of your SVN server. If not, you might require a svn dump/load cycle.
  • Hooks. If you have hooks on your SVN server, it is possible that you have to port them. Either by installing the same script language (think ActivePython or ActivePerl), or just rewrite them in vbs or equivalent.
  • Firewall. Just in case your server box is on a workstation edition, don't forget to open the firewall ports (quite trivial, but I got bitten once).
Steve Schnepp
  • 2,314
  • 3
  • 21
  • 28
6

Not sure about all the details, but keep in mind any hooks/scripts you have running on your repository will need to be rewritten as batch files.

Chris Shaffer
  • 768
  • 2
  • 8
  • 14
  • 1
    Can't you just install an interpreter for the scripting language that is used on the Linux SVN server? Another possibility is to wrap the Linux hookscripts with a batch file that calls the correct interpreter for the hookscript – Otherside May 04 '09 at 14:31
  • Certainly this can be handled in many ways. The important point though is that you will have to do SOMETHING to handle it, and it's an easy to forget piece (therefore a "gotcha"). – Chris Shaffer May 04 '09 at 16:38
  • depends, if the hooks are shell scripts, then they'll need to be rewritten. If they're perl or python scripts, you just need to get the Strawberry perl dll or python exe installed. – gbjbaanb Dec 30 '09 at 16:33
5

Dump/load would be the proper procedure and keep you safe from any problems. See the svn book

Vincent De Baere
  • 1,793
  • 10
  • 10
4

Running the VisualSVN Server on Windows has been very smooth. VisualSVN Server can host any number of independent Subversion repositories.

You can move repositories by any Subversion recommended method, it's a standard repository on both sides. Note the repository version, you may need to upgrade. Access permissions are windows oriented, you may have to change the way clients authenticate against the server. Good luck with hook scripts, if any. I hope they are written in a portable scripting language, e.g. Perl or Python.

gimel
  • 1,203
  • 8
  • 9
1

If you are attempting the move in reverse -- using svnadmin in Windows to make an dumpfile of a repository -- be sure to use the cmd.exe prompt and NOT the powershell.

I did this and found out (the hard way) that redirecting output from the powershell results in a Unicode file that svnadmin cannot read when you go to load the same file into the destination repository. It also takes a lot longer to run (and, obviously, the file is twice as big).

Tim Dunnington
  • 11
  • 1