On to tags and branching then. Tags allow us to give a more human friendly name to a specific revision of our folders/files. Branching gives us the capability to create a copy of the folders/files in our repository and have a different copy to work on – without fear of corrupting our main copy.
As you’ve probably already grasped every time you commit a changed file to the repository SVN gives the repository a new, incremented by 1, revision number. In a reasonable sized project, over a year or two, it’s not long before those revision numbers get into the thousands or even tens of thousands. So you’re likely to get to the point where you have a stable set of files that you know are in good shape and the SVN revision number might be r2343. Not easy to remember. So we can use SVN’s tagging feature and tag that same revision with the tag v1.2 Far easier to remember and in line with the version number we could be using when we release our software.
Branching is one of the core features in SVN that allows us to work on a different instance of the files the files that are contained in the repository. Say you have a set of files in your repository that are working perfectly. They’ve been released into a production environment and nobody wants to risk changing anything just in case you break something.
Along comes your end user who says wouldn’t it be great if we could add some functionality to support X, Y and Z. You and your team think pulling together a prototype version for this functionality would be a great idea. Your team want to work together and collaborate on this so you want to continue using SVN for this new work. However, you don’t want to contaminate your existing repository (with all the working code) with new prototype code that won’t work for some time.
What you need is a new copy of the files in your repository that you can make changes to without affecting the existing repository. Thinking ahead though you will want, at some point in the future, to combine this new prototype code with your existing working code.
These concepts of Tagging and Branching are explained in detail below. However, to support these capabilities we’ll need to prepare a new repository first.
Setting Up the Repository
Lets prepare that new repository so that it’ll support a trunk, branches and tags. Head back to the VisualSVN server app and select create new repository:
Follow the prompts, calling the repository something creative like ‘repo2’. Just make sure that on the ‘Repository Structure’ dialogue select the ‘Single-project repository option…
Note that we’re creating a repository here with Trunk, Branches and Tags folders. This is what gives us and SVN the capability to manage multiple instances of the same code/files. So, after you’ve created the repository you should have something like this on your Visual SVN Server…
Now we have a repository with the required starting structure. Folders to contain the different types of file collections. Trunk to contain the project files that are stable that we don’t want to interfer with. Tags to contain sets of files that have been tagged with a label relating to a specific ‘revision’ (more on this later). And ‘branches’ where we’ll a separeate instance of our files where we can work on our new prototype functionality.
At this point we can check out the contents of the repository (which doesn’t actually contain any files yet) on to our local machine. So create a top level folder on your local machine:
Right click on the folder and select ‘SVN Checkout’…
And on the check out dialogue enter the URL of the repository (remember you can get this from the Visual SVN server). Defaults like ‘check out directory’ and revision should be left as they are.
Your specific directory paths and URLs may differ slightly but we’re checking out the contents of ‘repo2’ to the new directory you’ve just created on your local machine. Now we’ll have the sub folder structure with branches, tags and trunk from the check out.
And now we’re ready to create some files and folders in the ‘trunk’ sub folder and check those in. It’s IMPORTANT that you create them in the ‘trunk’ sub folder like this
Doesn’t matter what you create in that directory… it’s just important that you do create the files/dirs in the ‘Trunk’ sub directory. Now we need to tell our SVN system about these new files/folders and then commit those files and folders into the repository. Add the files/folders first…
Confirm the files you need to add…
Accept the confirmations….
Then commit the files to the repository, adding a commit message as you walk through the commit dialogue boxes…
Once you’ve completed the commit we’re ready to start looking at adding branches to our code.
A branch then is a copy of the main code within the same repository. Essentially a separate set of files that you can work on independently. In the next section we’ll look at the steps you take to create and use a branch.
Branching consists of 4 steps:
1. create and prepare the repository so that it supports a trunk and branches
2. check in your files and directories to the repository trunk
3. create the branch based on a set of files at a specific revision
4. check out the branch
As we’ve completed steps 1 and 2 already we’re now ready to create our first branch. We’ll need to select the code we want to copy and make a branch of. We’ll bring up the Tortoise SVN context menu and select ‘Branch/Tag…’. This will allow us to create a copy of our code and place it in either the ‘branches’ or ‘tags’ sub directories (‘branches’ in our case).
In the “Copy (Branch/Tag) dialogue box we’ll already see the correct ‘From WC/URL’ set but we’ll need to update the ‘To path’ so that it shows the ‘/branches’ directory. click on the ‘Elipse’ button for this and select ‘/branches’ directory. Then specify the name you want your branch to be called.
You can add a message if you like and select a specific ‘revision’ of the files in the repository. Once you’ve clicked on OK you’ll see the confirmation window
From this we can see that we’ve finished creating our copy as a branch. We’re warned that what we have as our working copy (which is what we’ve just copied) is still a representation of the trunk and NOT the branch. So any changes we make locally and check in will be agains the trunk and won’t be committed to the branch if we check them in.
What we need to do, if we want to work on our new branch, is either switch or check out a copy of the branch code from the SVN server. We’ll opt for the check out.
To check out this branch then we’ll create a new sub directory in our workspace. In the example below we’ve created ‘MySecondRepo-branch’…
Then we’ll check this new branch of the code out into this folder. Right click and select ‘SVN checkout…’
It’s the next part that’s key. We need to make sure we’re checking out the branch, so the URL specified needs to reference the branch. You’ll see in the example below the end of the url specified svn/repo2/branches
And once this check out has completed you’ll see the finished log showing the files checked out from the branch and the revision that branch is labeled as
And we’ll see the new files checked out contained in the sub directory ‘branch-1.0.0’
From here the concept of modifying and checking in code is exactly the same as we’ve seen previously when using code checked out from the Trunk. You make changes to your branch-1.0.0 instance of the code. You can commit those changes back into the repository (in the branch).
When you get to the stage where you’re happy with your prototype work that’s on the branch you’ll want to look at merging the changes on the branch into the Trunk (where your stable working version of the code resides). Essentially you’ll want to combine both sets of code and promote your working prototype code into the main stable version of the code.
Now we’re ready to give our code a tag. Essentially a more user friendly lable to a set of our files residing in the repository at a certain point in time. First then lets take a look at our local copy of the repository files and see what revision number SVN has given them.
Find the ‘Trunk’ folder where you created your origional set of files and committed them to the repository. For example…
Then right click the directory, select Tortoise SVN and then ‘Repo-Browser’
The dialogue box you get presented with should default to the repository you’re using (if not go to your Visual SVN server application and copy the repo url again).
What you see here is the revisions of the individual files and the revision of the whole trunk part of the repository (if you hover your mouse over the ‘HEAD’ button you’ll see the main revision number). What we need to do is tag this particular revision so that it has a more user friendly number/name that we can refer to.
Right click on the ‘Trunk’ folder (we’re tagging the latest revision of the files in the Trunk – not the branch). Then select ‘Branch/Tag…’ in the Tortoise SVN submenu.
What we do with this Branch/Tag dialogue box is key now. Essentially Branching and Tagging are the same things in SVN’s eyes. We’re just creating a copy of the files at a certain point in time for a certain revision of the files. The different between Branching and Tagging is only that the completed copy is either to the ‘branches’ folder or the ‘tags’ folder in the repository.
On our dialogue box then (the top part) we’re copying from our ‘trunk’ directory to our ‘tags’ directory. If you click on the ‘…’ button you can change the destination from ‘/trunk’ to ‘/tags’ like this…
Then we need to append our Tag name to this ‘To path’ value. So we can add something like ‘v1.0.0’ in here like this…
Add a log message and make sure you pick the current revision of the files that you want to tag. The revision number should default to the latest revision with ‘Specific Revision in Repository’ selected already.
At which point you should see the confirmation dialogue box showing the completion of the tag opperation:
After clicking okay what we can do is check out that ‘tagged’ revision of our files into a new directory. So we’ll create a new sub directory at the top level in our workspace and give it the name of the tag we used earlier (e.g. v1.0.0)
Then right click on this directory and select ‘SVN Checkout’
On the check out dialogue box we’ll want to select the specific tag path within our repository. So click on the ‘…’ button for the ‘URL of repository’ section. Then in the Reposigtory Browser make sure you select the tag name directory for the tag you created earlier.
At which point you should have something like this…
Which means we’re checking out a set of files from our repository that have been tagged withe the name ‘v1.0.0’, and we’re checking them out to our sub directory on our local system called ‘v1.0.0’. Click on OK and you should see the confirmation message that the check out has finished…..
When you acknowldege this (click OK) and look in the ‘v1.0.0’ local directory you’ll have the set of files that relate to the revsion you gave this tag too.
Now, regardless of what you do on the Trunk or any of the branches, if you check out this Tagged set of files you’ll always get the same revision of the files. A crucial capability if you want to be able to revert back to a known set of files at any point.
There’s a lot to branching and tagging. Branching especially. Branching can get very complex particularly when it comes to managing multiple branches and then merging code back into other branches. Hopefully the basics we’ve covered here will get you started and help you grasp the main concepts. If you have grasped these concepts then it will put you in a good position to either start managing your own code with SVN and/or even joining an existing project that’s been using SVN for some time.
We know how to create a repository. We know how to setup our SVN client and import our initial set of files. And in the 3rd module in this series we saw how to check out and commit changes from/to the SVN repository. All pretty straight forward and easy to follow while just one user is working on one file.
It won’t be long though before you start getting warning messages from SVN that you have a conflict. It’s how you should go about handling these conflicts we’re looking at in this module.
What you’ll find is that that two people will be working on the same file and try to commit changes to the same file to the repository on the server. When this happens we get a conflict. Two users are trying to commit conflicting changes to the repository. This works as follows:
In short we have this….
- two users have checked out the contents of the repository to their local machines
- both users start editing one of the files on the local machines
(just so happens that they are both editing the same file)
- the first user commits his/her changes to the repository
- the second users tries to commit his/her changes to the repository too
- trouble is the second users changes would overwrite the first users changes
(so the first users changes would be lost)
- SVN warns user 2 that there is a conflict
- It’s down to user 2 to resolve that conflict
What we’ll see from SVN when the second user tries to commit their change is this warning from SVN:
It’s one of SVN’s key jobs to warn users that changes to files might be lost or overwrite if multiple users are making and committing changes to the same file(s). SVN does this by warning the user that there is a conflict. You can see this happening when you follow these steps:
Create a new directory (a 2nd directory) where User 2 will check their files out to
Check out the contents of the repository to this directory…
Using the Tortoise SVN Check Out command….
… And specifying the directory URL of the repository…
Note we’re simulating being user 2 here…. just by the act of checking out the same repository contents but to a different directory. In reality this second directory will be on a different computer and will be a different user.
Both directories now contain the contents of the repository and both are in sync with the latest updates that have been committed to the repository. You can check this with…
In this first instance you’ll see a list of modification you’ve made (if any) to your local files. You’ll need to click on the ‘Check repository’ button to see if anyone has committed changes to the repository so there are modification in the repository version that you’re missing locally.
Assuming you’re all up to date and in sync with the repository then we can go through the process of simulating a conflict and working through resolving that conflict. To do this we’ll go through these steps…
- modify a file in the first (user 1) directory
- commit the modified file in the first directory to the repository
- modify a file in the second (user 2) directory
- attempt to commit the modified file in the second directory to the repository
- deal with the conflict
So first, update one of the text files in the first directory and save your changes (you can use notepad or any text editor of your choice).
Then commit these changes to the repository
Adding a comment and clicking okay to complete the commit
Check you get a successful commit message and note the new revision number… then click OK.
Now we’ll repeat the process in User 2’s directory.
Update one of the text files in the second directory and save the changes
The commit the changes…
Note that you are committing changes from Users 2’s directory to the same central repository.
When you click OK you’ll be presented with a warning message like this…
SVN is warning use that the version of file1.txt that we updated was not done to the latest version of the file that was in the repository. If we commit this change then the latest version of the file in the repository will be overwritten and changes lost.
We need to resolve this conflict first. Without a resolution SVN won’t let us commit this change to the repository. So click OK to clear the ‘Commit Failed’ warning dialogue box. And at this point SVN will ask you if you want to update your local working copy
There are many ways to resolve conflicts. We’ll walk you through the update process that SVN prompts you to follow here. So click the ‘Update’ option on this dialogue box:
When you get presented with the update finished message you can clear this by clicking the okay button…
And then on the next dialogue box (that gives you the option to commit your changes again) click ‘Cancel’.
We’re cancelling this because I want to show you what SVN did when it attempted to resolve the conflict and updated your local copy of the file. When you click the update button what SVN does to your local file is this…
What you’re getting here is not 1, but 4 copies of the file you were working on. Those 4 files are….
This is the version of your file where SVN has tried to combine both the latest version from the repository and your local version with your latest changes.
This is your copy of the file with the changes you made. It’s exactly what you had before you attempted the commit.
This is the version of the file that you origionaly checked out of the repository (before you made your local changes)
This is the lastest version of the file from the repository with all the latest updates that have been committed by other users.
If you take file1.txt first thing you’ll notice in explorer is that it has a triangle with an exclamation mark against it. This is showing us that it’s in a conflict state and that SVN has combined your changes with those from the lastest revision found in the repository. Basically you need to do something with this file before you can resolve the conflict and commit the merged changes to the file back into the repository.
In short what we really want to do is take the lastest version of the file from the repository (file1.txt.r3) merge it with the file you had been updating (file1.txt.mine), rename the resulting file to the origional file name (file1.txt) and commit the merged file back to the repository.
The simplest way (and most logical to me) I find to do this :
- use a diff/merge tool to compare file1.txt.mine and file1.txt.r3
- merge the changes between file1.txt.mine and file1.txt.r3 (with a tool like winMerge)
- copy the resulting file (or rename it) to file1.txt (over writing the svn merge file)
- resolve the conflict
- commit the change back to the repository
In step 1 then we use a tool like WinMerge (or any merge tool of your choice; like winDiff, TortoiseDiff, etc) and compare your work with what is currently the latest version in the repository.
In the case of WinMerge select both files (file1.txt.r3 and file1.txt.mine) and then right click to select WinMerge
From here, for step 2, we can see our local version and changes on the left. And on the right the latest version of the file from the repository. We’ll merge the repository changes into our local version. So we’ll merge right to left.
We’re being careful here to pull changes from the repository version into our version (file.txt.mine) without over writing our changes. So the left hand version ends up with the repository changes and our changes.
Once they’ve been merged into file1.txt.mine we want to save this file.txt.mine. This is the file with ALL the changes in. The version of the file we want to push back in to the repository.
So save the file and close your merge tool.
Now for step 3 we want to make our file with all the changes the one called file1.txt. So, rename file1.txt to file1.txt.Svnmerged. Then rename file1.txt.mine to file1.txt.
Now we’ll have all our changes (the merged changes) in the file file1.txt. The new merged file1.txt should still show the SVN conflict warning triangle.
Now, step 4, we want to tell SVN that we’ve resolved the conflict. Right click on the file and select ‘Resolve’
And in the conflict resolution dialogue box now displayed just click okay to confirm the resolution and then click OK to the last confirmation dialogue box.
At which point we should be back to one of our usual states where SVN is just telling us that we have updated our local file and that it’s ready to be committed to the repository.
So for step 5 just commit the file back to the repository
Complete the commit and we should now have the latest revision of the file (revision 4 in this case) stored in the repository with the merged changes from both user 1 and user 2.
At this point we’ve completed the merge and everything is straight. Well almost everything. User 2 has the latest copy of the merged changes (revision 3). User 1 is still on revision 3. So a good last step for User 1 (and a step you should do on a regualr basis) is to update the local copy of the files.
So user 1 (in directory ../co-repo1-user1) should update their local copy by right clicking and selecting ‘SVN Update’
At this point everybody is in sync with the latest merged version of the files from the repository. And we’ve seen 2 users successfully collaborate and version control the same file on multiple client machines without losing anybodies updates to the files.
There are many ways to go about this conflict, merge and update process. The one described above is a little long winded but I beleive it’s the one that’s easiest to explaine and understand. It’s a process that helps highlight exactly what’s going on behind the scences with SVN. Once you’ve grasped this experiment with other approaches and see where that gest you too.
At this point, having completed module 1 and module 2, we have an SVN server, a repository in that server and we have files/directories in that repository. The whole point of this is to share files and version control them between different users. The next step then, is for you to check out the files from the repository. From here we can simulate another user checking out the files from that same repository. In this way we can see and learn how SVN deals with two people editing the same set of files at the same time.
In the last module we created two user accounts (user1 and user2). With your first user account then (the one that you just used to import the files) we’ll check out our set of files from the repository. Once checked out we’ll have a local copy of the files under SVN version control.
First then, In a directory create a new folder where you’ll check the repository contents out to.
It’s important that we don’t drill down into this folder. We want to check the contents of our repository out into this folder. So we right click on this folder and select ‘SVN Checkout…’
From here we’ll specify the location of the repository that we want to check our files out from. So something like…
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’.
Enter this value in the ‘URL of repository’ field. Checkout directory should already be defined, along with the parameters ‘Fully Recursive’ and ‘Head Revision’
Once you’ve clicked on ‘OK’ you should see confirmation that the files have been checked out to your directory.
And you should see a nice green tick against the folder indicating that the contents of that folder are in sync with the repository (which they should be because they’ve only just been checked out).
Drill into that folder and you’ll see the individual sub folders and files with the same green tick to indicate that they are in sync too.
Now we have the contents of the repository copied locally we’ll want to modify a file and check the files changes back into the repository. Check the changes into the repository so that the repository contains the latest versions of the files for everyone else to use.
Checking in your first change
At this point then we want to modify one of our files locally and update the repository with that change. So edit one of the text files and save your changes.
You’ll notice that once you’ve saved the changes the icon against the file changes from a green tick to a red exclamation mark. This shows us that our local file is no longer in sync with the repository.
At this stage then we need to update the repository with our changes. Right click on the file and select ‘SVN Commit….’
At this point Visual SVN will prompt you to enter a message explaining what the change was about. This is useful for other users who see the file has changed and will get to see some summary info about what the change was for.
The ‘Changes made’ section shows you which file you’re updating and what you’ve done with that file (e.g. modified it, added a new file or deleted an existing file). After you’ve clicked OK you’ll see the confirmation message showing that the commit has finished:
This confirmation message also shows you which version you’re now working with. SVN has incremented the version of your file (NOT the repository… just the file) to the next logical revision, revision 2.
If you want to review what’s happened to your files then you can check this by selecting the top level parent folder and clicking on the Visual SVN ‘Show log’ option.
The resulting dialogue box showing you a history of all the changes for your local files.
You can see the same information if you go back to the SVN server and check the repository on the server. Viewing that repository using a browser you should see something like this…
And viewing the individual files you can see the exact revision of each file
This is all very well but the whole point of this version control system is to share and collaborate on projects. So what happens when another user updates the file and your local copy becomes out of sync? That’s what we’ll look at in a future module when we cover updating, merging and conflicts.
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.
Setting Up Tortoise SVN Client
So the focus for 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 reposiotry in bluk. 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’ sub directory. 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 wrote down something like this earlier right?
If you’ve fogotten 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’ check box):
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 our first import/check-in of our code to the empty repository we created earlier.
Now if we go back to our VisualSVN Server applicaiton 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 origional 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 origional (non-version contorolled) 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 h ave a copy of these origional files on our local machine that ARE version controlled. It’s checking out a version controlling copy of these origional files that we’ll cover in the next module.
In this set of tutorials we’re going to take you through the basics of Subversion with Visual SVN Server and Tortoise SVN. Subversion (from here on in referred to as SVN) is a centralised Version Control System. That is, it’s a tool that allows us to version control files and collaborate on files. SVN deployed with Visual SVN Server gives us a server environment within which to maintain our files. Add to this a graphical user interface called “Tortoise SVN” and this gives us the simplest and quickest way for individuals to collaborate on files and version control those files.
SVN has been developed by CollabNet, and is currently maintained by the Apache Software Foundation. It’s open source project and is predominately a command line tool (both for Windows and Unix). The home of SubVersion is the Apache Org Subversion web site where you can download the source code (you’ll find many mirror sites that host the binaries for various platforms).
Separately to this a company called VisualSVN Software Ltd have developed an SVN server application that works as a graphical front ends to the SVN server component. Then we have an independent Open Source project (GPL) called Tortoise SVN that provides a client front end for windows. At the core though is SVN. We’re just using Visual SVN Server and Tortoise SVN client because they are quickest and easiest ways to use SVN and start learning about SVN. Other front ends are available!
1. Visual SVN Server: a server applications, the central repository that holds all the files you want to version control, called Visual SVN Server
2. Tortoise SVN: the client application called Visual SVN, that allows you to manage your files locally, get your files from the server and commit your updated files to the server.
Let’s just go back to the main features of a version control system for a second. Those are …
a. version control of files
Version control of files is a simple concept in it’s own right. It just means we want to have a file that starts out as the “first version”. We make changes and save a copy of the file as the “second version”. If we want to go back too our original version we just open the ‘first version’ of the document.
b. collaborate of files
When we collaborate on files all we’re looking for is the ability to share a file and for two or more people to be able to update that file. We can achieve this by either sending the file round in emails as an attachment or having the file on a shared file system where many people have access to this one file.
Both of these concepts in there own right are simple concept that are easy to implement and easy to work with. The complexity starts to come when you what to combine both concepts and start having more than 2 or 3 people working on the files.
So for example you have a single file on a server and that file is at version 1. I take a copy of this file and updated it. At the same time you take a copy and update it. I copy version 2 of the file back to the server so that it’s available for everyone else to look at and update. Then shortly after you copy your version of the file back to the server. Technically this is version 2 too. The worst bit though is that you’ve copied it back and overwritten my changes. All my work, in ‘my version 2’ is lost.
Or you could approach this another way. You have a single file on your computer and that file is at version 1. You send this in an email to your colleague and he/she updates it to version 2. At the same time though you update your version 1 of the file on your local system. Now you have version 2 of the file. And your colleague has version 2 of the file….. but both version 2’s of the file are most likely different. Who now owns the master?
It’s issues like this that SVN was designed to solve. However, being a command line tool doesn’t make SVN particularly easy to work with so the Visual SVN tools were developed to help people like you and me work with SVN. And it’s working with SVN, Visual SVN server and Tortoise SVN that we’ll be looking at over the next five tutorials.
We’ve broken this series of tutorials down into the following five parts:
- Setting up the central SVN Server
- Setting Up Tortoise SVN Client and Importing
- Check Out and Commit
- Resolving Conflicts
- Tags and Branching
In this, part 1, we’ll start by installing an SVN server from the Visual SVN website.
Installing Visual SVN Server
From this web page:
Download and install the appropriate version (32-bit or 64-bit) for your system. Run the .msi installer, accepting the licence agreement, the default settings and selecting the ‘Standard Edition’.
Once the install has completed click finish, making sure you select the ‘Start VisualSVN Server Manager’ option.
On the Visual SVN Server start page there are two things that are two parts we’re interested in. First is the ‘Repositories’ section where we’ll create a repository to store our files. The second is the Users folder where we’ll define our users that will be allowed access to our repositories. That’s all we need to learn the basics, everything else is superfluous for now.
Creating Our Users
Let’s create some users first then. We’ll need to create two users so that we can simulate the actions of two users editing the same file later in the course. Follow these three steps:
1. click on the Users folder node and right click to select ‘Create new user’
2. enter the user credentials and a password
3. repeat the above to create a 2nd user
Creating Your First Repository
You can think of a repository as a container for a group of files. That might be a group of files for a particular project. At this point we have our server running and we have two users configured. Now we just need to create that repository where we can store our files.
1. click on the Repositories node and right click to select ‘Create New Repository’
2. select the ‘Regular FSFS repository’ option and click ‘Next’
3. give your new repository a name and click ‘Next’
4. Select the ‘Empty Repository’ option and then ‘Next’
5. Finally, to keep things simple, select the ‘All Subversion Users have Read / Write’ access and then create the repository
On the final dialogue box you’ll see confirmation that your repository has been created. You’ll want to note these details down as these details will be needed when you point your SVN clients to the repository.
At this point you should have 2 users created and 1 repository shown in the Visual SVN Server explorer side panel.
And with the Repository you’ve just created you’ll see the URL for that repository listed in the ‘repo’ panel on the right hand side.
Checking the Repository
At this stage you can check the successful creation of the repository and that your users have access by right clicking in the ‘repo’ panel and selecting ‘Browse’
You should see a browser window open and a dialog box prompting for credentials. You can enter the credentials for one of the users you created:
Once you’ve logged in you should see the contents of the repository displayed in your browser window:
Not a lot to see at this stage but you can pick out the URL for the repository (shown in your browser address bar) and the name of the repo displayed top left. You’ll also notice the revision which is shown as ‘HEAD’. This just means that you’re viewing the latest version of all the files in the repository. Except that at the moment we don’t have any files. It’s adding those files as a user that we’ll look at in the next module.