Subversion and TortoiseSVN – a Basic PrimerSubversion and TortoiseSVN – a Basic Primer

Blake Medulan

2008

What is it?What is it?

Subversion (abbreviated SVN) is an open source version

control system that facilitates source code development

by multiple software developers.

•Web Access

•SSH

•Windows Shell

Why we use itWhy we use it

SVN allows us to easily

• maintain backups of source code

• automate deployment

• keep copies of every single version of the code

• prevents developers from overwriting each other's work.

• roll back to previous versions of code

VocabularyVocabulary

• SVN : abbreviation for subversion

• Head Revision: The latest (or “youngest”) revision in the

repository.

• Conflict: Two competing versions of the same file

• Working Folder: Folder (local or server) that you check out

the code to in order to edit

• Commit : Publish new files to repository

• Branch: a line of development that exists independently of

another line, yet still shares a common history if you look far

enough back in time.

VocabularyVocabulary

Base : The revision number of an item in a working copy. If the

item has been locally modified, this refers to the way the item

appears without those local modifications.

Prev: The revision immediately before the last revision in which

an item changed. Technically, this boils down to

COMMITTED#1.

WebDAV: Distributed Authoring and Versioning.” RFC 2518

TortoiseSVNTortoiseSVN

• TortoiseSVN is a Windows shell extension that allows you to

access SVN repositories within Windows Explorer.

• Basically, any folder on your hard drive (or remote server) can

be turned into an SVN folder and used to store a revision of

an SVN repository

TortoiseSVNTortoiseSVN

• Once a directory is identified as version controlled, the

following icons are used

Checkouts and CommitsCheckouts and Commits

• To work with SVN version-controlled source code, you must first 'check out' the current

version of the code (or possibly an older version, if necessary)

• Updated code can then be 'committed' back to the SVN repository as a new version of

the source code, and

• Subsequent attempts to check out the latest version of the code will acquire this newer,

updated version.

The “Checkout” operationThe “Checkout” operation

1. Create a working folder locally

2. Right click on folder select SVN Checkout

3. Enter repository location

(http://10.1.1.250/project_xxx)

(http://subversion.webfeat.mci/project_xxx)

4. Select working folder

STEPS

The “Checkout” operationThe “Checkout” operation

5. Enter your username and password

6. Checkout process begins

7. Working folder now contains latest version

The green check means that the folder contains SVN

files and is version controlled.

STEPS

The “Commit” operationThe “Commit” operation

• 1. Right-clicking on the file, sub-folder, or

repository folder (whichever will cover the entire

set of files/folders you have changed), and

select SVN Commit....

• 2. Enter log message

Only use accurate, descriptive comments so others

can understand how the new version of code you

are creating differs from the previous version!

STEPS

Rename Files and FoldersRename Files and Folders

1. Checkout the file or folder to your machine

2. Right-click on the file or folder, and select the menu option SVN Rename

3. Type in the new name, and the icon for the file or folder will change to;

4. Run a Commit and the repository will be updated with the new name

Delete Files and FoldersDelete Files and Folders

1. Checkout the file or folder to your machine

2. Right-click on the file, and select the Delete... option from the TortoiseSVN menu:

Adding Files and FoldersAdding Files and Folders

1. Checkout the latest version

2. Move the new file(s) and folder(s) to the location you want them in the repository

3. Right-click on the file(s) and folder(s) you want to add to the repository, and select the SVN

Add.

4. To make the change stick, run a Commit and make sure the check boxes are checked for

adding the items you want to add

UpdatesUpdates

1. Update your local snapshot of the repository to the latest version available by running an

Update Operation.

2. Right-click on a folder containing versioned files and folders in it, and select the SVN

Update... menu option.

NOTE:

Only the files already checked out will be updated (or deleted, if they were deleted in the

repository since you last updated)

Only the files already on your hard drive will be touched, and they can only be deleted or

overwritten with the latest version of the file.

Conflicts – the scenarioConflicts – the scenario

• In the following example, we will be committing a change to the repository. Note: please

don't actually make a commit to the repository for this tutorial - just read along! (We don't

want the iris4 repo to get messed up with a bunch of 'SVN practice' commits.)

• If you have modified any of the files you have checked out, added new files to the folder (or

a sub-folder) where you have versioned files, or if you have deleted versioned files, you will

have to commit these changes to the SVN repository to try and make them stick. I say try

here because it is possible that the commit operation will fail if your changes conflict with

someone else's changes

ConflictsConflicts

When you try to commit your file you get the following message

You then run an Update operation, and you will see the following:

ConflictsConflicts

After you click OK, the folder containing main.cpp will now have several new, non-versioned

files in it:

1

2

3

4

ConflictsConflicts

main.cpp.mine

This is what main.cpp v31 looked like after you

changed it (no conflict markers).

main.cpp.r31

This is what version 31 of main.cpp looked like

(the file you checkout and then modified).

main.cpp.r32

This is what the current version of main.cpp

looks like (on the server).

main.cpp

During the Update operation, conflict markers

were inserted into this file.

ConflictsConflicts

You can now right-click on the file main.cpp, and under the TortoiseSVN option, select Edit

Conflicts:

ConflictsConflicts

You can now right-click on the file main.cpp, and under the TortoiseSVN option, select Edit

Conflicts:

BranchingBranching

The Never-Branch system

(Often used by nascent projects that don't yet have runnable code.)

Users commit their day-to-day work on /trunk.

Occasionally /trunk "breaks" (doesn't compile, or fails functional tests) when a user begins

to commit a series of complicated changes.

Pros: Very easy policy to follow. New developers have low barrier to entry. Nobody needs

to learn how to branch or merge.

Cons: Chaotic development, code could be unstable at any time.

BranchingBranching

The Always-Branch system

(Often used by projects that favor heavy management and supervision.)

Each user creates/works on a private branch for every coding task.

When coding is complete, someone (original coder, peer, or manager) reviews all private

branch changes and merges them to /trunk.

Pros: /trunk is guaranteed to be extremely stable at all times.

Cons: Coders are artificially isolated from each other, possibly creating more merge

conflicts than necessary. Requires users to do lots of extra merging.

Occasionally /trunk "breaks" (doesn't compile, or fails functional tests) when a user begins

to commit a series of complicated changes.

BranchingBranching

The Branch-When-Needed system

(This is the system used by the Subversion project.)

Users commit their day-to-day work on /trunk.

Rule #1: trunk must compile and pass regression tests at all times.

Rule #2: a single commit (changeset) must not be so large so as to discourage peer-review.

Rule #3: if rules #1 and #2 come into conflict (i.e. impossible to make a series of small

commits without disrupting the trunk), then the user should create a branch and commit a

series of smaller changesets

Pros: /trunk is guaranteed to be stable at all times. The hassle of branching/merging is

somewhat rare.

Cons: Adds a bit of burden to users' daily work: they must compile and test before every

commit.

OverviewOverview