Version Control with Subversion

1. Version Control withSubversion

2. 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

3. 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: BitKeeper, Code co-op, TeamWare • Client-server model - developers use a shared single repository • Local only: Revision Control System (RCS) • Open-source:CVS, CVSNT, OpenCVS, Subversion, Vesta • Proprietary: a lot

4. 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 1980s • 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

5. Subversion (SVN) • Goal: functional replacement for CVS • Started in early 2000 (by CollabNet) • 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

6. 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 toevery file, and even changes to the directory tree itself, such as the addition, deletion, and rearrangementof files and directories.

7. 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

8. 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

9. 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 plug-in for Eclipse. Subclipse can be installed and updated from within Eclipse: http://subclipse.tigris.org/install.html

10. 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/

11. Check-out the project A check-out creates a local working copy from the repository. • 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

12. Make changes and commit A commit (check-in) occurs when a copy of the changesmade to the working copy is written or merged into the repository. • 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 • To compare local and remote files double click on file

13. 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 has your latest changes in it. • filename.ext.rOLDREV - the file that was the BASE revision before you updated your working copy. It is the file that you checked out before you made your latest edits. • filename.ext.rNEWREV - 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 <<<<<<< filename your changes ======= code merged from repository >>>>>>> revision

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

15. 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 • Allows to talk about “revision 2524” • Unique identifier for a state of project • Simple way to tag (next slide) • Each revision corresponds to a single commit • Contains author, log message, and date

16. 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

17. 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

18. 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

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