Subversion – An Overview

Subversion is an open source version control system. It is a centralized

system for sharing information. At its core is a repository, which is a
central store of data. The repository stores information in the form of a
filesystem tree—a typical hierarchy of files and directories. Any number
of clients may connect to the repository, and then read or write to
these files.

What makes the Subversion repository special is that it remembers

every change ever written to it. This allows you to recover older
versions of your files and examine the history of how and when your
data changed, and who changed it.

To manage the multiple file versions, Subversion uses a Copy-Modify-

Merge model as an alternative to locking. In this model, each user's
client reads the repository and creates a personal working copy of
the file or project. Users then work in parallel, modifying their private
copies. Finally, the private copies are merged together into a new,
final version. The version control system often assists with the
merging, but ultimately a human being is responsible for making it
happen correctly.

This is much more efficient than the Lock-Modify-Unlock method

which means only one person can be editing a file at a time.

Advantages of Subversion:

• Every change will be recorded and monitored.

• Every change can be undone easily.
• It preserves a historic record.
• Commits are atomic
Subversion Basic Work Cycle

The typical work cycle looks like this:

• Update your working copy

o Update
• Make changes
• Examine your changes
o Show Changes
o Compare revisions
• Possibly undo some changes
o Revert Changes
• Resolve Conflicts (Merge Others' Changes)
o Update
o Resolve Conflict, if any
o Merge
• Commit your changes
o Commit

A few definitions and commands

Check out:
Check out is the process of making a copy of a project from a
repository into your local filesystem. This checked out copy is called a
working copy.

Working Copy:
A Subversion working copy is your own private working area.
It contains a COPY of those files which you will have been editing on
the website. You can edit these files however you wish, in the usual
way.

Branch:
Branches are separate lines of development isolated from the main
line, to avoid making unstable changes to the main line. Once the
changes are stable enough the branch can be merged back into the
main project (the trunk).
Tag:
A tag is just a “snapshot” of a project in time. Tags are used to mark
milestones or release-quality projects, so used to keep your work
isolated from any changes. Tags are really useful for keeping track of
important events in the life cycle of your project.

Both branch and tag are ordinary directories created by copying. A tag
remains a tag as long as no one commits to that directory. If people
start committing to it, it becomes a branch.

Revision:
Each time the repository accepts a commit, this creates a new state of
the filesystem tree, called a revision. Each revision number is a
snapshot of the way the repository looked after each commit.

Commit:
An svn commit operation can publish changes to any number of files
and directories as one single transaction. Each commit is treated as an
atomic transaction: either all the commit's changes take place, or
none of them take place.

Svn diff:
It displays the differences between two revisions or paths. It is usually
used to compare BASE and the working copy.

Merge:
It is used to apply differences between two sources to a working copy.
It is similar to diff except that instead of displaying the differences on
the terminal, it applies them directly to the working copy as local
modifications.
A better name for this command would be diff-and-apply, since that
is what happens. Two repository trees are compared, and the
differences are applied to a local working copy.

Show Changes:
This displays the changes in the file since the last commit. Equivalent
subversion command is svn status.

Update:
It updates your working copy with any changes committed to the
repository since the last time you've updated your working copy.

Show Log:
This displays the commit log messages from the repository.

Disk Browser:
This opens the project directory window.
Repo Browser:
The Repository Browser displays all files and directories within the
repository.

Patch:
Patch is the outcome of diff of url and working copy.
Create Patch: Create Patch command is used for creating patch.

Apply Patch:
Apply Patch command from context menu is used for applying patch
file.

Switch:
Switch a current working copy to the newly created copy in the
repository.

Revert Changes:
It is used to undo all local edits. Reverts any local changes to a file or
directory and resolves any conflicted states. It removes all
uncommitted changes.

Get Lock:
Lock a file.

Release Lock:
Release the locked file.

Update to Revision:
The working copy will be updated to the HEAD revision or the specified
revision number.

Add Solution to Subversion:

Adding a project to Subversion.

Get Solution from Subversion:

A working copy will be created at the specified location.

Set Working Copy Root:

Can set or change working copy directory.

Cleanup Working Copy:

Recursively clean up the working copy, removing working copy locks,
and resuming unfinished operations.

Blame:
Show author and revision information in-line for the specified files or
URLs.

Unlock:
Unlock working copy paths or URLs.
How to create tags:
A tag is a snapshot of a project in time, and may be used for keeping
track of significant events and major releases of the project. To create
a tag, copy the code to the tags directory of the project. The directory
to which the code is copied is the symbolic name for the tag, eg:
Release 1.01. The copy serves as a reference point storing the files in
the project as they were when the tag was created.
The command ‘svn copy’ may be used to create a tag, as illustrated
below.

Eg: C:\Repositories >svn copy /calc/trunk \

/calc/tags/release-1.0 \
-m "Tagging the 1.0 release of the 'calc'
project."

Backing up the repository

Svnadmin hotcopy:
This subcommand makes a full “hot” backup of your repository,
including all hooks, configuration files and database files. This
command may be run at any time to make a safe copy of the
repository, regardless of whether other processes are using the
repository.
The command is as follows: >svnadmin hotcopy repo_path
New_repo_path

Eg: C:\Repositories>svnadmin hotcopy VisSVN2 Vis2Copy

Now Vis2Copy is a fully functional subversion repository which may be

used as a replacement in case something goes wrong with the live
repository.

Svnadmin dump:
Subversion provides the svnadmin dump command to extract the
contents of a repository into a portable dumpfile. A dump- dumpfile file
contains information about each revision in the repository and can be
backed up like a regular file.

Svnadmin load:
The svnadmin load command takes the contents of a dumpfile and
loads it into a repository. This can be used to restore from a backup or
to copy a repository to another location.

How to backup and restore in VisualSVN Server:

1. Open VisualSVN Server.
2. Right-click on Repositories -> All Tasks -> Start Command
Prompt.
3. In Command Prompt, type as follows:
C:\Repositories>svnadmin dump reponame > dumpfile
Eg: >svnadmin dump VisSVN2 > dumpfile1.041113
This creates a backup of VisSVN2 in the file dumpfile1.041113
4. Create a new repository VisSVN2bkp.
>svnadmin create VisSVN2bkp
5. Restore from dumpfile to new repository
>svnadmin load VisSVN2bkp < dumpfile1.041113
6. In client system, right-click on empty folder and click SVN
Checkout.
7. Select URL of repository which could be something like
file:///\server/Repositories/VisSVN2bkp, and press OK. Working
Copy is created.
8. Double click on solution file VisSVN2.sln in the folder to open the
restored project.

How to make incremental backups:

Doing full backups everyday will take up too much space, so
incremental backups lets you specify revision ranges, to produce
smaller dump files.

Say you already have a dumpfile with revisions 1 to 50, and the new
revisions are upto 54. Then you can create an incremental dump file by
running
>svnadmin dump –incremental – revision rev1:rev2 repos
Eg: >svnadmin dump --incremental --revision 50:54 \
/home/VisSVN2
Subversion Clients

Tortoise SVN

TortoiseSVN is a free open-source client for the Subversion version

control system.

Salient Features:
• TortoiseSVN was intentionally developed as an extension for the
Windows Explorer and thus integrates seamlessly into the
Windows shell.

• The status of every versioned file and folder in TortoiseSVN is

indicated by small overlay icons. That way you can see right
away what the status of your working copy is.

• All Subversion commands are available from the explorer context

menu. TortoiseSVN adds its own submenu there.

VisualSVN
VisualSVN is a transparent integration of Subversion version control
system to the Visual Studio development environment. With VisualSVN
one can easily see the full history of modifications and restore previous
versions of the project.
Conversion from VSS to Subversion:
The steps to be followed in order to migrate from VSS to Subversion
are:
1. Set up the Subversion server.
2. Set up the Subversion repository.
3. Prepare the VSS database for migration.
4. Run the migration.
5. Load the dumpfile into the repository.
6. Compare the repositories.

1. Set up the Subversion server

2. Set up the Subversion repository

Create a new Subversion repository.

3. Prepare the VSS database for migration

• Copy (if possible) the VSS database to the fastest storage
possible before starting the migration, such as a local hard
drive.
• Ensure that no one will be accessing the VSS repository
during migration. This may be done by removing the share
rights, or by restricting write access.
• Avoid performing major changes to the VSS repository prior
to migration. It is better to do any restructuring after
migration.
• Make sure the VSS repository does not contain any serious
errors.
• If there are errors, try to fix them. If files are corrupt, delete
them if possible.
• Disable TortoiseSVN.

4. Run the migration

Run the executable command. It will be something like the
following:
vss2svn.exe --vssdir <dir>
where <dir> is the path of the VSS repository.
After the migration is finished, there will be a dumpfile in the
directory where the migration was run. Write access is required
now. The ssphys command will create temporary files and these
are stored in the root directory.

5. Load the dumpfile into the repository

Remove any obsolete projects or files from the dumpfile.
Load the dumpfile.
6. Compare the repositories
Do some checks against the two repositories.
Checkout the trunk from both VSS and the new Subversion
repository and perform a full directory comparison against the
two.