Subversion

From DesigningPatterns

Jump to: navigation, search

Contents

Background

Subversion is an open source version control system that is meant to replace CVS. It also can be seen as a competitor to commercial packages like Clearcase. Designing Patterns accesses subversion over ssh.

Installation

yum install subversion
mkdir /usr/svn
svnadmin create /usr/svn/designingpatterns

If importing the repository from another machine:

svnadmin load /usr/svn/designingpatterns < svn.dump

Then, in order to permission the repository so that any developer can write to it (through svnserve)

groupadd svn
chgrp -R svn /usr/svn/designingpatterns
chmod -R g+w /usr/svn/designingpatterns

Every developer should be a member of the svn group.

Customization

  • Add or change anon-access = none to /usr/svn/designingpatterns/conf/svnserve.conf in order to prevent anonymous read and write access.
  • The EDITOR environment variable will tell subversion which editor it should use for commit messages; this should be set in /usr/designingpatterns/etc/profile.
  • A graphical diff and merge (diff3) tool is a necessity. Designing Patterns uses xxdiff right now, although meld also is available.

General Characteristics

  • URLs are used to specify file locations.
  • Changesets are committed atomically.
  • Revision numbers are associated with repositories, not with individual files. Thus, there may be no changes in a file between two different revision numbers.
  • Subversion offers copy on write semantics when copying files.
  • Subversion's "branch" concept is very similar to Clearcase's "view" concept. Both are version controlled copies of the source code, created with the intent of making changes and then merging back into the trunk.
  • svn move is not a "true" move command; it actually is a copy and then a delete (and thus the move destination is a different file to the subversion system than the move source, which are different semantics than those offered by UNIX). This is a real weakness of subversion. Suppose developer 1 and developer 2 check out working copies of a directory. Developer 1 edits file_a. Developer 2 then moves file_a to file_b. At this point, developer 1 commits the changes to file_a back to the repository. The next time that developer 2 updates his view, the changes that developer 1 made to file_a will not be reflected in file_b (since, according to subversion, file_b is a different file than file_a). Instead, file_a will reappear in developer 2's working copy (which is weird; if developer 2 deleted file_a, why should subversion allow it to appear again?). When developer 2 commits the changes to the directory (including the file_a->file_b move), then the deletion of file_a will be committed (even though the svn update caused file_a to reappear in the directory), blowing away developer 1's changes to the repository (since file_b never received those changes). This is a very broken use case; Clearcase, by contrast, has a first class move operation and correctly handles this (file_b continues to receive updates to file_a before the move has been committed).
  • A variety of work flows (no branches, branching for every task, branching for some tasks) are supported.
  • Branches create additional complexity, because the trunk and the branch share the same set of revision numbers (since all files in a repository share one set of revision numbers). In particular, merging changes to the trunk into the branch and merging the branch changes back into the trunk can be tricky.
  • Changes in the repository are not reflected in working copies until the update command has been run.
  • Subversion can leverage 3rd party diff and merge tools; Designing Patterns uses xxdiff, which is a graphical diff and merge tool.

Workflow

Create a "working copy" of a directory in a repository with the checkout command (the working copy will be put into the ~/working_copy directory). For example:

~/working_copy> svn checkout svn+ssh://svn-host/usr/svn/designingpatterns/Applications/psgrep .

Designing Patterns maintains a wrapper around svn checkout called dpcheckout. The above command could have been written like:

dpcheckout Appications/psgrep .

Update the private copy with the latest changes in the repository (this is called rebasing in other systems) with the update command. For example:

~/working_copy/psgrep> svn update .

Commit the changes in the private copy with the commit command. For example:

~/working_copy/psgrep> svn commit .

Files cannot be committed if someone else has committed changes to the repository (thus bumping the file's revision number in the repository). The status command shows the current status of a file.

~/working_copy/psgrep> svn status psgrep.rb

The log command shows the change history of an element (file or directory)

~/working_copy/psgrep> svn log psgrep.rb

Reference

  • svnadmin create path creates a repository.
  • svn add file_name makes file_name (which could be a directory name) a subversion element.
  • svn mkdir directory_name creates a directory element in the working copy.
  • svn delete file_name (or svn rm file_name) removes file_name (which could be a directory name) in the working copy.
  • xx-svn-diff will run a diff loop, popping up a diff window for each file against the repository version, over all of the changed files below the directory in which it was run within the working copy (thus, if you want to diff all of the changed files in a working copy, you should run it in the working copy's top level).
  • svn diff will invoke xxdiff to display the differences. svn diff can diff any two revisions against each other.
    • svn diff file, where file is a working copy file, will show differences between file and the working copy's base revision (which is the revision that was created either by the checkout of the working copy or by updating the working copy). This also can be done explicitly with svn diff -r BASE file.
    • svn diff -r HEAD file, where file is a working copy file, will show the differences between file and the latest revision of file in the repository.
  • Both svn help command_name and svn command_name --help will provide help for command_name.

Links

Personal tools