In the first tutorial we looked at why we need SVN and setting up our own Visual SVN server. When working with your team at work or collaboratively over the net, you probably won’t need to setup the server. This will probably already be in place and you’ll be given an account that allows you access. We’ve setup our own Visual SVN server instance because it’s the quickest way to get started and to help us learn. Your own SVN server gives you an environment in which to practice and experiment.
Once the server and repository are configured we need to setup our client to access this repository. The client allows us to pull files out of our central repository and push files back into that repository. The act of pulling files from the repository is known as a ‘Check Out’. The act of putting files back into the repository known as a ‘Commit’. Before we do either of these actions though we’ll start with an ‘Import’. An ‘Import’ is used to put a bunch of files (files that aren’t already version controlled by SVN) into the repository for the first time.
So the focus of this tutorial, installing Tortoise SVN and importing our initial set of files so that they are controlled by SVN. To start we’ll need to download and install the Tortoise SVN client from here…
Run this installer and work your way through the prompts (accepting most of the defaults).
Worth adding the command line client tools at this point…
These utilities can come in handy at times, especially when integrating with other tools (like TestComplete for example).
You may need to restart your machine after this install but once completed you should be able to confirm the install by opening an ‘Explorer’ window and right clicking…
This should show you a couple of top-level menu items that Tortoise now provides us with; SVN Checkout and Tortoise SVN. The Tortoise SVN menu item then having a whole new sub menu related to SVN actions.
At this point, we’re ready to start working with files in our repository on our Visual SVN server. We have two main options:
1. SVN Checkout: with this option, we’ll pull the files from a particular repository on our SVN server.
2. TortoiseSVN -> Import: with this option, you can push files and directories into the repository to start things off.
We have a new SVN Server without any files in the repository. There’s not a lot to check out. So we’ll start by importing some files into our repository on the server. In a future module, we’ll go through the SVN Checkout process followed by adding a handful of new files to our existing repository. For now, though we’ll create some test files and directories on our local machine and then add them to a repository on the server, with the SVN ‘Import’ command.
With the ‘import’ command we can push a batch of files and directories into an existing repository all in one go. It’s the simplest way to get started if you have a lot of files to add to a repository in bulk. Think of this as the start point where you have some local files/directories that aren’t under version control. You want to start version controlling those files and sharing them with other people. So you put them in a central place…..you import them into the SVN repository on the SVN server. Once they are in that repository they’re available to you and others to work on.
First, though we’ll need to create some test files and directories to get us started. Create an empty directory on your system called “SvnDemo”.
Doesn’t matter where you place this directory on your system, you just need to have the ‘SvnDemo’ subdirectory. Under this directory we need to create the following folder and file structure:
You can add a bit of text to some of the text files to get started too, but essentially you need to have this…
Then go up a level in the directory hierarchy and select the Import option:
At this point, you’ll need the URL for the repository you created earlier. You write down something like this earlier right?
If you’ve forgotten what this URL is then you can go back to the VisualSVN server app and right click to select ‘Copy URL to Clipboard’.
Note that at the end this has the name of the repository where we’ll be checking this in. In our example above ‘repo1’. Add this URL to the import dialogue and add some initial ‘Import message’ that just describes what you’re doing.
Then click okay to import all your folders and files to your repository on the server. You’ll be asked to enter your user credentials as shown below (making sure to check the ‘Save authentication’ checkbox):
Once you’ve clicked OK you be at a point where you see a list of all the files imported into the repository with, hopefully, a ‘Completed’ message.
You’ll notice that it’s given an initial revision of ‘1’. Our first revision number for the first import/check-in of our code to the empty repository we created earlier.
Now if we go back to our VisualSVN Server application and click on refresh we should see all of our newly imported files on the server.
Note the structure though. The import process didn’t import the top level folder (‘SvnDemo’ in our example) it just imported the folders and files within that directory. The repository (‘repo1’ in our example) on the server now contains the original set of files that we created:
Or from the SVN servers point of view the following files…
The critical bit is that when the next person checks out this repository, they will get these files with NO top level directory…
Also, take note of the fact that (AND THIS IS IMPORTANT) your local copy of the files is not version controlled. Whilst you have imported your files into the repository the local files are not under version control. The import process doesn’t touch, modify, add to or update these files in any way. These are still your original files. This set of files are the originals that are not version controlled.
Whilst the original (non-version controlled) files are still on your local machine. We now have our ‘master’ set of files stored on our SVN server. When we get a copy of these from the SVN server (using the ‘check out’ command) we’ll have a copy of these original files on our local machine that ARE version controlled. It’s checking out a version controlling copy of these original files that we’ll cover in the next module.