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