Version Control with Subversion

Quick Reference of Subversion

What is Version Control?

An alternative to sending zipped source code back and forth by email and manually integrating changes between more than one person

“Version Control” is meant to solve the following problems: Users editing the same file concurrently

overwriting each other Keeping users sharing the same source code

that is in constant change in sync Keeping a running history of changes (and who

did them) Recovering from disastrous changes in source

code

What is Version Control? Is WONDERFUL for group work (and is an industry

standard!) Also called “Source Control" Subversion aims to be a simple to use, secure,

and safe way to do Version Control

Workflow Without Source Control

Benefits Group Work

No zipping/unzipping from emails Manually merging is very rare Might be the only solution when you have more

than 2 or 3 participants

Group and Individual Work History of changes Sync when using multiple computers Easy backup

Requirements If you can develop on it, you can run

subversion on it

Can be configured to run on standalone custom server (easy), apache (advanced but featureful), or local on file system.

Some Definitions

Repository – the place (can be server or location on hard drive) that the “master” files are stored. Managed by Subversion

The repository is a centralized store for data: Stores data in form of a

filesystem tree Provides read/write

access to the stored data Remembers any

modification made to it

Some Definitions Working Copy – a “checked out” code you

make your changes in Users edit their working copy locally. Changes are then committed to the

repository. After a commit, all other users can access

the changes by updating their working copies to the latest revision.

Some Definitions Commit – applying a change to the code on

the repository

Update – downloading and merging all changes from repository into your working copy

Some more definitions Changeset – refers to a “commit,” is a list

of files touched during that commit. Every changeset is ordered starting from 1 to however many commits there have been

Conflict – When a user edits and commits a file while another user is editing the same lines. The second user can’t commit until he manually merges the conflicting lines. Rarely happens and is avoidable!!

What is Subversion? Robust, easy, and popular implementation of

Version Control

Very similar but “better” than CVS (a popular older Version Control System Everything is versioned (including renames and

file meta-data) Atomic Commits (never a bad partial commit!) Many deployment options Well documented

Named “SVN” for short

http://subversion.tigris.org/

How Working Copies Track the Repository The working copy is made up of two parts:

a local copy of the directory tree of a project

an administrative directory named .svn in each directory, storing version control information

.svn is a hidden directory.

How Working Copies Track the Repository

Information stored in .svn directories: For each file, Subversion stores:

the working revision of the file a timestamp of the last update of the file

Given this information, by talking to the repository, Subversion can tell which of the following four states a working file is in: Unchanged and current Locally changed, and current Unchanged, and out of date Locally changed, and out of date

How Working Copies Track the Repository

Unchanged, and current The file is unchanged in the working directory, and no

changes to that file have been committed to the repository since its working revision. An svn commit of the file will do nothing, and an svn update of the file will do nothing.

Locally changed, and current The file has been changed in the working directory, and

no changes to that file have been committed to the repository since you last updated. There are local changes that have not been committed to the repository; thus an svn commit of the file will succeed in publishing your

changes, and an svn update of the file will do nothing.

How Working Copies Track the Repository

Unchanged, and out of date The file has not been changed in the working directory, but it

has been changed in the repository. The file should eventually be updated in order to make it current with the latest public revision. An svn commit of the file will do nothing, and an svn update of the file will fold the latest changes into

your working copy.

Locally changed, and out of date The file has been changed both in the working directory and

in the repository. An svn commit of the file will fail with an “out-of-date” error. The

file should be updated first; an svn update command will attempt to merge the public

changes with the local changes. If Subversion can't complete the merge in a plausible way automatically, it leaves it to the user to resolve the conflict.

How Working Copies Track the Repository

Locally unchanged

Locally changed

Current Commit –do nothingUpdate – do nothing

Commit –publish your changeUpdate – do nothing

Out of date(new version at repository)

Commit –do nothingUpdate – get the latest changes

Commit – “out of date” errorUpdate – attempt to merge(need to resolve the conflicts)

What is TortoiseSVN A very easy to use

windows-integrated Subversion front-end

Makes your right click menus look like this…

Basic Commands on Windows

Revision A revision is the state of the filesystem tree

after a commit. The state of the repository after each commit is

called a revision. To each revision, a natural number is assigned

which identifies the revision uniquely. Revision numbers always increase, starting from

0.

Revision Revisions are assigned to the whole tree: a

certain file can be left unchanged through different revisions

Files in the repository have always the same revision

Files in the working copy might have different revisions

Branches

A Branch is an independent line of development that shares a common history with another line of development

It begins life as a copy of something and moves on from there generating its own history

Branches What are they good for?

Branches are usually used to try out new features without disturbing the main branch of development with compiler errors and bugs

As soon as the new feature of the branch is stable enough the branch is merged back into the main branch (the trunk) and removed

Tags A tag is a snapshot of a project in time, E.g.

each repository revision is a tag - a snapshot of the filesystem after each commit.

To make it easier to remember snapshots, Tags get human-friendly names like „release-1.0“.

Like Branches, Tags are created as copies of something

A tag is to save the state of a project that one later wants to refer to

Are Branches and Tags Diff? No, not really. For Subversion Branches and

Tags are the same they are directories in the filesystem and handled

in the same way. Yes - From a user perspective

Branches are lines of development. That means, you make changes to them.

Tags are used to fixate a certain state of your development, so you should not commit to a Tag - although you could do that.

Repository Layout Each Group has its own toplevel directory that

only the team members have access to.Example: Project directory of group CI317 ishttp://206.180.209.64:8080/SVN/CISCourse/CIS31708FA Within each of the group directories three

subdirectories exist for software development:Trunk - Here the main development takes placeBranches - Here you create Branches from TrunkTags - Here you create Tags from Trunk

A quick run-through of subversion Import our existing code to the repo Check out a working copy Make changes

Add a file/folder Remove a file/folder Edit a file

Commit Revert Comparing

Import your code

Do the import

The URL is http://206.180.209.64:8080/SVN/CISCourse/CIS31708FA/ID

Check out your working copy Make a folder, right click on it, choose

“checkout” Fill in the URL

Checking out a Working Copy

Finished!! The green check marks indicate two things:

the file is under subversion "control", and that the file is equivalent to the most recently checked out version of

the file (called the BASE).

Add a folder/file

Add the documents (to the local working space)

To add to repository, you need to commit

Delete a folder/file

Delete some documents

Edit a file

Make an edit

Icons change on files

Commit changes Nothing changes until you commit

Reverting (rollback) If you have not committed

If you have committed

Comparing to old revisions Right click > SVN >

Diff

Comparing right before commit Double click

View the logs

Avoiding Conflicts Commit Often!

The less time you spend with code you havn’t committed, the less likely someone will edit a line you’ve not committed.

Commit in small chunks! The less code you change and don’t commit, the

less likely someone will edit a line you’ve not committed.

Split your project into more than one file! You should be doing this anyways

What not to do… Don’t commit broken code

If someone else updates, they will have broken code too and will be unable to work unless they fix your mess

Don’t commit temporary/binary files We don’t need files like vore.vcproj.SNOWFIRE.philipd.user or

any .exe or .obj files. They waste space! You MAY commit graphics as long as they aren’t too big. Binary files don’t get merged.

Don’t commit ginourmous files Remember, if you put it in the repository you force people to

download it! A good alternative for optional files that are big is to put them

on a web server – particularly if they don’t change

What to do.. When you commit, describe in the log as succinctly

and clearly what you changed as possible This information will help others know what you did to the

code

Add your new files If you make a new file, make sure to right click and add it

to source control. If you don’t, others won’t be able to get it.

EXAMPLE: In a game, you add a bitmap file. If you forget to add it to the subversion, when others synchronize, they download your code but not the bitmap. Now when they run the game, it crashes because it can’t find your file.

What to do.. DO NOT COMMIT TO REPOSITORIES THAT YOU

DO NOT OWN UNLESS YOU HAVE TALKED WITH AN OWNER OF THAT REPOSITORY FIRST!!!

Basic Work Cycle Update your working

copy. svn update

Make changes. svn add svn delete svn copy svn move

Examine your changes. svn status svn diff

Possibly undo some changes. svn revert

Resolve conflicts (merge others' changes). svn update svn resolve

Commit your changes. svn commit

Getting the Software If you are hosting (or downloading with

command line) you will need Subversion(

http://subversion.tigris.org/project_packages.html) If you are using under windows you will need

only TortoiseSVN (http://tortoisesvn.net/downloads)

http://svnbook.red-bean.com/