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
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…
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
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
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/