Version Control Systems with Subversion (SVN) and Tortoise

Overview A repository is a version controlled collection of files (e.g., source code, data, configuration files, executables, etc.). Version controlled: Each version of each controlled file is kept is a manner that allows users to Document version changes Check for modifications Compare differences between versions Merge versions/resolve version conflicts Rollback to earlier versions

Overview Version control is valuable in situations where Teams want to co-develop code, documents, etc. Tracking and documenting changes is important The ability to roll back changes may be necessary The “safety net” of a central backup is desired SVN repositories are centralized, meaning there is one master copy and any number of local (or working) copies. The master copy resides on the SVN server Local copies reside on client hosts

Creating the Master Repository The master repository can be created on any machine that can act as a host server (most any networked computer) The master should be universally available In this class, we use joseph has the SVN server Joseph is widely available to students and faculty on and off campus Integration with Apache allows for browsing the repository from the web or management by an SVN client Set up instructions for an SVN repository are on-line at our course web site (here).here

Creating the Working Repository The working (or local) repository (or copy) can be created via an “SVN Checkout” command on any machine with an SVN client There are a multitude of SVN clients --- TortoiseSVN being one of the most popular Clients also exist as plug-ins for common IDEs such as Eclipse, NetBeans, Visual Studio Tortoise is an extension to Windows Explorer which adds SVN functionality to the right-click menu Set up instructions for Tortoise are on-line at our course web site (here).here

Typical Change Process Client checks out master repository (once) as a local copy Client makes changes to local files Client commits changes (whole or in part) to master copy. Changes are accepted immediately (no conflict) Changes are not accepted, because of editing conflicts (files need to be merged)

Gotchas Mismatched commits Textually exclusive (but logically incompatible) changes to separate files Using multiple SVN clients on the same local copy Multiple clients can corrupt the local repository Keeping multiple local copies Confuses users as to which copy is the active repository. Rather trust the VCS to distinguish among versions.

Demo Creating the master repository Creating the working copy Head revision versus named revision Adding files to the repository Document changes Browsing the repository Updating Making changes/committing Checking differences Merging files