Setting up VisualSVN for Local Projects

By: Brian Dobberteen

This one is pretty straightforward, but potentially useful to those of you not yet familiar with source control.

In a nutshell, source control allows us to keep a historical record of any changes we’ve made to files over the course of time. This is beneficial because if multiple people are working on the same project, it can be very easy to accidentally overwrite someone else’s changes that you may not have been aware of. It also gives some peace of mind to know that copies of your teams’ work are safe from accidental local deletion, corruption, and other such maladies.

The source control system that we will be using today is known as Subversion.

Subversion (SVN) is an open-source, widely used, and in my experience, very solid choice for a version control system (VCS). To be sure, there are many others out there, such as Git, Mercurial, Team Foundation Server, CVS… the list goes on.

We’re going to quickly learn how to get an SVN server up and running on your Windows box with the aid of two software packages: VisualSVN Server and TortoiseSVN (which will serve as our client).

First, let’s grab these two packages – try and be sure to grab the latest stable release offered at each site.

VisualSVN Server: http://www.visualsvn.com/server/download/

TortoiseSVN: http://tortoisesvn.net/downloads.html

Installing VisualSVN Server

Fire up the VisualSVN Server installer that you downloaded from the above link. Follow the on-screen prompts – the default settings should be fine. Once that’s done, it should offer to take you right to the VisualSVN Server Manager Console – click OK and we’ll find ourselves at a screen that should look similar to:

VisualSVN Server Management Console

The next step is to create at least one user and one repository:

Adding Users and Repositories

Creating a new user couldn’t be simpler – just decide on a username and enter/confirm a password.

Setting up a new repository is equally simple – all you need to do at this point is give it a name, preferably something meaningful to you and your team. For now, don’t worry about the ‘Create default structure’ checkbox and make sure that it’s not checked.

And that’s it! Told you it was simple!

Installing and Using TortoiseSVN

Again, first step will be to run the TortoiseSVN installer that you downloaded earlier. Just accept any default settings. Once the installer is done, it will prompt you to reboot – go ahead and do so.

Once back in Windows, we find that our right-click context menu has some new additions:

Next, we’ll want to create a folder to create what is known as our ‘working copy’ of the project that will now be under source control.

In whatever location you deem appropriate, create a new folder, preferably with a name that matches the name of the repository you created earlier in VisualSVN Server.

Once that’s done, right click the new folder, and then click on ‘SVN Checkout…’ in the context menu, which brings us to:

All that’s needed for this screen is to type the URL of the repository you’ve created. I’m using localhost here, and this may or may not work. If it does not, replace localhost with the name of your machine.

Finally, replace where I show ‘Site1’ with the name of the repository you created earlier.

Leave all other settings as they are, then click OK.

Because we’re connecting over SSL, TortoiseSVN will prompt you about whether or not you want to accept the security certificate. Choose ‘Accept Permanently’ and you’ll be good to go for now and in the future.

Now, you have an active ‘working copy’ that is under version control by SVN!

Adding Project Files to SVN

If you already have an existing project, made up of files and directories, the first step will be to copy those items to the folder you just did the SVN Checkout to.

Note that it is easy to tell at a glance what folders/files are under source control, and what their current status is:

So, let’s add some files to our working copy folder and place them in to the repository.

The first step is to select the files that you want to place in the repository by first selecting those files/folders, right clicking your selection, and choosing TortoiseSVN -> Add…

Which brings us to:

Leave everything checked, then click OK.

TortoiseSVN will show the progress of the Add – if everything went ok, it should say so. Click OK to close the window.

Note that now each file/folder icon will be overlaid with a blue plus sign, indicating that it has been added but not committed.

The final step is to Commit these added files/folders by again, first selecting the ones you’ve just added, right-clicking that selection, and choosing ‘SVN Commit…’:

Which brings us to:

The area circled in red above is a text area to enter a log message detailing what you are committing. Personally, I think it best to always try to include some meaningful comment about what you’ve included/changed in the commit.

Messages like: ‘Pulled the javascript out of index.html and placed it in scripts/myscript.js” can definitely be of help.

Though the log message is optional for us, some shops may require a log message on each commit.

Don’t be lazy – always enter a commit log message!

Once you’re done entering your message, click OK. TortoiseSVN will show the progress of the commit, ending with a display of what revision you are now on. Since this was the very first commit, it makes sense that you should see that you are now at Revision 1.

Day to Day Usage of SVN

Frequently Updating and Commiting your project files is an excellent habit to get into. We already know what a Commit does, and I bet you can guess what an Update does.

To try it, select any files you’d like to have the latest copy of so that you can be sure that you’ve picked up any changes by other members of your team. Right click these selected files and click SVN Update…

Since you are the only one who has committed anything to this point, you’ll see that nothing has changed and that you are still on Revision 1.

Next Steps

Add more users, one for each member of your team.

Add more repositories, one for each of your projects.

Individually make and commit changes, being sure to update after each one to ensure you have the latest code.

Experiment with features such as ‘Locking’ which will prevent other team members from modifying the locked file until you release that lock.

Hopefully this has been of some use to you CVS n00bs out there – next time, we’ll go over conflict resolution, an important tenet of version control.



Leave a Reply