Version Control with Subversion What is Version Control

Version Control with Subversion

What is Version Control Good For? • Maintaining project/file history - so you don’t have to worry about it • Managing collaboration on files and projects - so multiple developers can work on the same set of files • Managing releases - so you know what files are in what version

Version Control Systems • Version control system keeps track of all work and all changes in a set of files, typically the implementation of a software project, and allows several (potentially widely-separated) developers to collaborate. • Classification and examples: • Distributed model - each developer works directly with their own local repository, and changes are shared between repositories as a separate step • Open-source: GNU arch, Bazaar • Proprietary: Bit. Keeper, Code co-op, Team. Ware • Client-server model - developers use a shared single repository • Local only: Revision Control System (RCS) • Open-source: CVS, CVSNT, Open. CVS, Subversion, Vesta • Proprietary: a lot

CVS • The most famous and popular open source version control system is CVS (Concurrent Versions System) • It was invented and developed by Dick Grune in the 1980 s • Latest release: 1. 11. 22 / 2006 -06 -09 • Overview: • Client-server architecture • The Repository (server): The magic place that holds all versions of everything • Working Copy (client): The place where you get to do whatever you want • The CVS program manages moving files between the two

Subversion (SVN) • • Goal: functional replacement for CVS Started in early 2000 (by Collab. Net) Current version: 1. 4. 5 / 2007 -08 -27 More than just a replacement for CVS: • • • Directory versioning Atomic commits File and directory metadata Faster network access Requires less network access Branching and tagging are cheap

Fundamental Concepts – The Repository • Subversion is a centralized system for sharing information • At its core is a repository, which is a central store of data • Can be accessed via a HTTP or HTTPS connection • Repository remembers every change ever written to it: every change to every file, and even changes to the directory tree itself, such as the addition, deletion, and rearrangement of files and directories.

Fundamental Concepts – Working Copy • A Subversion working copy is an ordinary directory tree on local system, containing a collection of files • Subversion provides commands to commit your changes and merge other people changes into your working copy • Each working directory has a. svn directory (administrative directory) • • Repository password are stored in each. svn folder Stores a original copy of each file in directory

Basic Subversion Work Flow • • Get a working copy Make changes in your copy Test them locally Integrate them with any changes made to the Repository Commit them back to the Repository Repeat these steps until a release is ready Tag the release Start making changes again for next release

How to start • Subversion client is distributed as command-line tool and can be downloaded at: http: //subversion. tigris. org • Another one choice - Tortoise SVN, a Subversion client, implemented as a windows shell extension: http: //tortoisesvn. tigris. org/ • For development more convenient is to use Subclipse plugin for Eclipse. Subclipse can be installed and updated from within Eclipse: http: //subclipse. tigris. org/install. html

Create repository location In Eclipse switch to “SVN Repository Exploring” perspective and create new Repository Location: Type repository URL, e. g. http: //java-eim. googlecode. com/svn/trunk/

Check-out the project A check-out creates a local working copy from the repository. 1. 2. 3. Right-click on a module for check-out, choose “Checkout…” option Choose to check-out using e. g. New Project Wizard Check-out e. g. as General Project

Make changes and commit A commit (check-in) occurs when a copy of the changes made to the working copy is written or merged into the repository. 1. 2. 3. Switch to another perspective, for example, “Java” View and modify files in your working copy When finished and ready to commit certainly(!!!) synchronize with repository, to avoid conflicting changes (probably somebody already modified the same files)!!! Right click Team… Synchronize with Repository 4. To compare local and remote files double click on file

Resolving Conflicts • • • Once in a while, you will get a conflict when you update your files from the repository Subversion places conflict markers—special strings of text which delimit the “sides” of the conflict - into the file to demonstrate the overlapping areas For every conflicted file Subversion places three additional files in directory: • filename. ext. mine - your file as it existed in your working copy before you updated your working copy - without conflict markers. This file <<<<<<< filename has your latest changes in it. your changes • filename. ext. r. OLDREV - the file that was the BASE revision before ======= you updated your working copy. It is the file that you checked out before code merged you made your latest edits. from repository >>>>>>> revision • filename. ext. r. NEWREV - the file that your Subversion client just received from the server when you updated your working copy. This file corresponds to the HEAD revision of the repository. • Manually resolve a conflict, execute resolved command, commit

More Concepts and Features • • Revisions Tagging and branching Metadata (properties) Locking • • • History of changes [Team Show History] Compare different revisions • • Lock is a piece of metadata which grants exclusive access to one user to change a file Select two versions from history Compare Directories are versioned items Deletes and moves are recorded Copy sources are remembered

Revisions • Each time the repository accepts a commit, this creates a new state of the file system tree, called a revision. • Revision numbers are global, rather than per-file • • Unique identifier for a state of project • • Allows to talk about “revision 2524” Simple way to tag (next slide) Each revision corresponds to a single commit • Contains author, log message, and date

Branches and Tags • 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. • Subversion implements “cheap copies” – branches are simply copies of the main trunk • • Tag is just a “snapshot” of a project in time. Tags are copies which are never changed • Might not even be necessary if you simply record the global revision number that built your product

Metadata • Any file or directory can store properties • Properties are name/value pairs • Some standard properties exist • • • svn: ignore svn: mime-type svn: eol-style • etc. • User-defined properties are allowed • Property values can be text or binary

Subversion Hosting • When you decided to use Subversion in your project, then you will need a server where to place your code • There are free hosting systems, for example CVDDude, berlios. de • List of sites that offer Subversion hosting: http: //subversion. tigris. org/links. html#hosting

References • Subversion home http: //svn. subversion. com/ • Book “Version Control with Subversion” http: //svnbook. red-bean. com/ • Subclipse http: //subclipse. tigris. org/