Turnleaf Design Ramblings of a junior developer

Taming of the Subversion, a SVN primer; part 2

In part one I went over how to get SVN setup and configured on your system. In Part two I will get into the day to day activities of using SVN. In this part of my SVN primer I will cover; Checking out, committing, updating, synchronizing, branchings, and tagging. I will also go over some terminology to help make things a little more clear. I will be using subclipse as my SVN client in this part of the primer. I find using SVN from within an IDE to be more natural and including directions for both subclipse and tortoiseSVN to be confusing and there is very little difference between the two anyways.

Terminology:

Head Revision – Refers to the most recent revision in the repository.

Trunk – The main working directory of a project.

SVN Commands:

Checking out – To retrieve a project from the repository open up the “SVN Repositories” view and navigate to the project you wish to check out. Following with the example from part one it would be SVNProject>Trunk>SVNProject click finish when the next screen pops up. I find this method to be the easiest and quickest way to checkout a project.

Committing – When you have modified a file (or created a new file) you will need to “commit” it for the file to be included in version control. Subclipse keeps track of the files you have modified and when they are out of sync with the repository they display an icon next to that file stating so, subclipse shows a brown box with a white asterisk (new files are a question mark). To commit your file right click on the file(s) you wish to commit and go to team>commit . You will be presented with a pop up box, you here you will put a message of why you are committing a file, ALWAYS put a message. Messages will server as a quick reference when looking over a files history (explained below).

Updating – To get the latest file(s) from the repository you will need to run an update. To perform an update select the file/folder(s) you want to have updated and right click team>update to HEAD.

Conflicts – A conflict arises when you have a file that is out of sync with version control and you have edited line(s) of code that have been checked in since the last time you have run an update. Because SVN cannot itself determine which piece of code is correct, you must manually look at the code and determine which is correct. Here is an example of a conflict:

1.This is the change you made
2.This is the change that has been made in subversion since you last updated
3.This is several versions of the file that is in conflict
1.XXXX.java.mine is the file on your local machine
2.XXXX.java.r(lowest number) is the most recent file you retrieved from the repository
3.XXXX.java.r(highest number) is the newest file in the repository

In order to resolve a conflict you need to determine which change is correct. In this case I will keep my change, so I will delete the SVN markup (<<< .mine, ====, etc.) the change I do not like. So my file will like this:

You will also notice a weird little symbol that looks like a X with a square over it, this is the “conflict” symbol. You cannot commit a file to the repository that is in conflict. To remove the conflict you must delete the .java.mine, java.r(lowest number), etc. files. Once this is done you can commit your file to the repository. To resolve the conflict right click on the file and select Mark as Resolved, then select the action you wish to take. The "conflicts have been resolved option" uses the current file in your code view, "my file" will use the ".mine" file, incoming file will use the .r(highest number), base will use the .r(lowest number) file. (Thanks Mark!)

Branching – Most work on a SVN project is done in the “trunk” folder. There maybe times though when a change needs to be made to a project, but that change cannot affect the trunk, or a change need to be made, but it cannot affect code that will be going to production. In these scenarios a “branch” is crated. A branch is a copy of the current head revision of a file(s) that is placed in a separate folder (typically under “branches”). To create a branch right clicks on the file/folder you wish to branch and go to team>branch/tag>select your destination ({project name}/branches>name the new branch

Tagging – A tag is like a branch, however it represents snapshot of a project instead of a working directory. Typically a tag represents a project version or code that has been pushed to a production environment. When you attempt to commit a file to a tag a warning message is displayed stating a file is being committed to a tag. To create a tag team>branch/tag>select your destination ({project name}/tags>name the new tag.

REMINDER: When you branch or tag a project, the branch/tag is created off the Head revision of what is in the repository NOT what is stored locally on your computer.

View history - Subclipse allows you the the view the history of a file(s) stored in the SVN repository. The history view will show when the file has been modified (checked into SVN), the revision number, and the comments when the file was committed. To view the history of a file right click on it go to team>show history.

Reverting – Reverting allows you to retrieve a previous version of a file from the repository. Reverting is typically done to get rid of unwanted changes or for debugging reasons (i.e. a bug is known to exist in version X of a project). A neat thing SVN allows you to do is revert an entire project to a specific revision. When this is done all files are not the same revision number, but the version number they where at the time that revision was made. To perform a revert right click>team>update to revision>select the revision you wish to revert to.

This will conclude part two of the SVN primer. In part three I will go over a few more day to day task of using SVN. I will also go into a few advanced topics like setting up SVN properties which can be quite useful. Check back later this week for part three! If you have any questions please let me know.

Technorati Tags: Best practices, Subversion, SVN

Related posts:

1. Taming of the Subversion, a SVN primer; part 3
2. Taming of the Subversion, a SVN primer; part 1
3. Setting up SVN over http on Linux