Using Subversion with FTP
For simplicity, this article focuses on MS Windows machines, but it can easily be adapted to other environments.
NetDrive (link to search only - related products are also available for mapping FTP drives)
Subversion is a great tool for version control on any kind of document, but one limitation that's been bugging me for a while is the fact that you can't use it with the web host of your choice. Although there are remote subversion hosts, generally you will need to pay for them, so I figure that while I have the disk space with the host I already have then I may as well figure out how to use that space.
Basically, using recommended methods, if you need to store your subversion repository remotely, you must run a subversion server. This is a simple exercise if you have an apache host or have admin control over the server, but the trouble is that if your host server isn't apache, most website hosts will not let you run server-side software, and this includes the subversion server, so your options are significantly reduced. Subversion does let you reference UNC paths to work with repositories, so this got me thinking that FTP paths are not that much different in the scheme of things (well, vastly different if you look internally at file handling methods, but we're looking at things generally). Unfortunately the subversion documentation and support sites explicitly say that FTP is NOT supported. There are probably good reasons for this, but as always I couldn't take no for an answer and continued my investigations regardless...
My line of thought was how do I make an FTP path into a UNC path? After a bit of searching I discovered Novell's NetDrive. Once you install NetDrive, the process of mapping an FTP drive is very simple. You simply add the ftp address, pick a drive letter, enter your user name & password and connect!
Now that you have connected your FTP site to a drive, you can treat it and its files like you would with any other drive on your computer. The cut-down ftp menu in Windows Explorer is replaced with the complete context menu available to all files. This means you can do things like open and edit files directly and view and edit their properties seamlessly.
Creating a Repository
For the article I will concentrate on the basics and let you the reader study how to structure repositories to best fit your needs. So for the example I will describe a standard repository without getting into the specifics of subversion, such as branching, tagging, linking and merging - however all of these methods are available using the FTP method, nothing is lost.
Firstly, create an empty folder somewhere and open it in explorer so that the right pane shows no files. In the right pane, right-click, and under the TortoiseSVN menu, select 'Create Repository Here'.
Ensure you select the FSFS repository option.
Now create a new folder on your remote storage (preferably offsite - below the wwwroot folder) and copy all the files from where you created the repository to the new folder on the remote storage. You now have an empty remote repository! This is the one task that differs from working with a local filesystem or a mapped network path - creating a repository directly does not work through NetDrive, you must create it locally and copy it to the remote location.
Populating the Repository
The next step is to create the basic structure for your repository. Create a new empty local folder. Under that folder, create the folders 'trunk', 'branches' and 'tags'. Right-click on the parent of the trunk branches and tags folder and from the TortoiseSVN menu, select 'Import...'.
You will now be prompted for the server location and a log message. Click the elipses button to choose the server location and locate the folder which contains your remote repository. Note that this is the drive letter you assigned using NetDrive, and you are now treating the remote drive as if it were a network share or local. In the log message, type in 'Setup Repo Structure' and click OK to import the structure.
The empty folders will be imported, ready for populating.
Now you can populate the repository with actual version controlled files. For the exercise, create another new folder locally, make a couple of new text files in it, and save some text into the files. Right click on the folder containing the new text files and select 'Import...' from the TortoiseSVN menu.
This time, TortoiseSVN will have a memory of the server location in the dropdown list, rather than having to use the elipses and navigate all the way to the repository. After you select the repository location from the list, you need to add '/trunk' to the location. This is critical for maintaining your repository structure. In the log comment, type 'Initial Import'.
Click OK and let TortoiseSVN complete the importing of the files.
Now that you have imported the files you want to version control you can now delete the folder containing the text files on your local drive, it is no longer needed. In fact, to use the version control effectively you don't want that copy floating around possibly causing confusion as to what version it is. The whole idea of using these methods is to simplify version control. The server should always have the current file versions and it is up to the client to keep up-to-date with the server files.
Working with Version Controlled Files
Create a new folder on your local drive called 'Working'. Right-click inside that folder and select 'SVN Checkout' from the TortoiseSVN menu.
From the dropdown list, select the repository location we created earlier - select the one with '/trunk' at the end; you will almost always work with the trunk folder until you develop more advanced version control techniques.
Leave other options at the default and click OK. Now your text files will be recovered from the repository under full version control.
Note that the files now have a tick icon overlayed over the original icon. This signifies that the files are unmodified since being checked out from the repository. The overlay icon will alert you to various file conditions so that you can act upon them accordingly.
To test version control, open one of your text files and add a new line of text at the end. Save the file and exit the editor. You may need to refresh the file list, but once correctly shown you should see a distinctively different icon which alerts you to the fact that the file has been modified.
Right-click the modified file and select 'SVN Commit" from the TortoiseSVN menu to commit our modifications back to version control.
Enter a log message describing what your modification is and leave all options at the default.
Once you click OK, your modifications will upload to the repository.
The cycle is complete. You have created a repository, moved files you want to version control into the repository, completed an initial checkout, made a modification and checked the modification back in.
As you can see, the process is rather simple. Once your repository is setup and you have a working copy, you just need to do the odd commit to maintain your version history and maintain the integrity of the repository. If you are already familiar with subversion you will have noted that the process is exactly the same as using a network share, or even a local drive. If you are new to subversion you will have both learnt the basics of version control with subversion, as well as learning a valuable technique for creating a central repository for all your valuable files, whether it be sourcecode, documents, artwork, or any kind of file for that matter.
Using this technique you can move to any computer connected to the internet, install the appropriate client software, and you will be able to get full access to your online file repository with full version control. Bear in mind that depending on your web host's services it is generally still your responsibility to backup your own data. If your host suffers a catastrophic loss of data, then so do you - unless you maintain a backup regime. The difference to your normal backup regime is that you don't need to store multiple versions of your documents on multiple CD's, you need only maintain one backup version - although you would normally not rely on just one CD/DVD, you would probably keep two to be certain. I used to have my sourcecode backed up by date and version on multiples of CD's. Now I can throw away old versions.
This process is very effective in maintaining your repository, and it is very convenient. You can use this repository as effectively for sole use as with a worldwide distributed team. There is much literature on how to organise teamwork with subversion, but the general rule of thumb is to both make use of branching and enforce regular commits to ensure major works don't just vanish or never see the light of day.
An observation in general use is that this really is most effective with a broadband connection. Even if you are working with a relatively small repository you will find working over a modem is almost prohibitively slow. If you aren't in a hurry and can leave the modem connected for hours on end for long commits then you can still make use of a slower connection. I found commits of individual files were processed in reasonable time, while whole directory checkouts were mind-numbingly slow.
The best bet is to test the technique first and plan your attack. If all your development occurs from one PC then you can maintain a local repository. If you are like me and access sourcecode from all over the place then it's nice to be able to login anywhere and get your beloved sourcecode when you want.
To realistically operate with a distributed team I highly recommend using a subversion server. Read the subversion documentation for recommendations from the experts.