Setting up SVN on a hosted server

Question

I was just wondering is someone would kindly help me with my installation of subversion on a hosted (dedicated) linux webserver that I'm struggling with.

I have a dedicated Linux server that I rent and the team have installed subversion for me (/usr/bin) and that is all. I have been told that I can use PuTTY to connect to the server which I have been able to do.

Now I have 15 plus websites hosted on the server and WHM is installed to manage these; therefore I would like to create a repository for each and put the source code into each. Then I would use TortoiseSVN to create repositories on my local machine and then it would be good to apply those commit to the live server.

I have read through elements of the SVN book; however, I'm really struggling and would appreciate some help in a) setting up a repository correctly and creating all the necessary permissions and security and then b) how do I get the changes from my local machine to the live server - again help would be greatly appreciated in what I assume is creating a hook script to transfer files to the live server?

Thanks

P.S. It would really help me if someone could provide simple steps for the above and the code required as I've been at this for some weeks now and cannot seem to get it underway.

Answer 1

On your server:

1) Ensure subversion is installed -- yum/apt-get/etc should make it quite easy.

2) Create a directory to hold a repository: mkdir /some/repository/path

3) Use svnadmin to create the repository layout: svnadmin create /some/repository/path

4) Import your sources:

$ cd /path/to/your/code
$ svn import -m "initial import" . file:///some/repository/path/trunk

NOTE: this imports the code into the repo, but does NOT create a working copy! So, next:

5) Move your original files out of the way, and check out a working copy:

$ cd ..
$ mv /path/to/your/code /path/to/your/code-presvn
$ svn co file:///some/repository/path/trunk code

5.5) You probably want to ensure that people can't browse your .svn directories via the web server. For apache, something like the following in httpd.conf should do it:

<Directory ~ "\.svn">
    Order allow,deny
    Deny from all
</Directory>

6) Test your site, ensure permissions are correct, etc. Checking out a fresh copy may have created issues. It's probably a good idea to document (or even better, script) any changes that will need to be done to properly configure a newly checked-out copy.

7) To get a local copy for development, use a repository URL like svn+ssh://[email protected]/some/repository/path/trunk I'm not familiar with tortoisesvn, but if you were using the standard command-line tools, you'd check out your project like:

$ svn co svn+ssh://[email protected]/some/repository/path/trunk

You then can make changes to your local working copy, and commit thing (svn commit -m "description of changes"). When you want to move those changes to your production system, ssh into the box, cd /path/to/your/site, svn -u status (to preview the changes), svn update to bring everything up to date.

Hopefully this is helpful.

I also can't suggest enough that your read more of the subversion documentation to understand what's going on under the hood. Also, make sure you know what you're doing before trying this stuff on anything important. You can create test repositories, with bogus data, and do some experiments until you're confident that you know what you're doing.

Answer 2

is it a dedicated server or shared hosting? if it's shared hosting then I think you're out of luck, but if it's a dedicated server, then you just log in and install the app

I would use something like port 8080 for the service to listen on, and I would definitely use VisualSvnServer Standard as it's super easy to install and configure.

Also, if you're willing to purchase VisualSVNServer, then you would have full access to configure it remotely.

http://www.visualsvn.com/server/licensing/

I personally use the standard version and RDP into my server when I need to create a new Repo... that way I can use the VisualSVN GUI and know that it will work without hassle.

Answer 3

Some terms of art here will clarify issues you face. The important thing to understand about SVN is that it is a client-server system. A posix FS readable copy of the repository is called a checkout; the centralized server will not have such a thing. Moving changes to a checkout to the central repository is called a commit; checkouts other systems have made are not affected; they must update to see your new commit. All changes must pass through the central SVN server, you cannot comunicate from one checkout to another. Scripts that are run on the server after specific SVN events are called hooks. For example, a script that sends out an email after every commit is called a "postcommit hook."

So what you must do is:

1. Set up an server to host one SVN repository per website, and make it accessible via SVN+SSH. This will use SSH for authentication(Ie, "this is Bill"), but leave authorization ("Bill can write to this repo") up to you. Typically repositories are stored in /var/lib/svn/, so make your repos there, like svnadmin create pwnguin.net. A new empty repo is created. Use tortoise to checkout the repo to your desktop and add files. The url will be something like svn+ssh://example.com/var/lib/svn/pwnguin.net.

2. Once you've got checkout and commit working for your local box, set up each website to use a checkout for DocRoot. Make sure to block off access to any .svn files in the your server configuration, as it can be kinda dangerous to leave around. Make a change on your workstation and commit it, then try to update the checkout manually and verify that information is flowing how you want.

3. Once you've gotten SVN deployment working, you can use that to automate it with postcommit hooks. If all the websites are on the same Linux server as the SVN server, this is pretty easy to script, if they're on different boxes, it's still pretty easy but you'll need to know how to set up SSH without passwords safely.