Subversion
From DesigningPatterns
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 = noneto/usr/svn/designingpatterns/conf/svnserve.confin order to prevent anonymous read and write access. - The
EDITORenvironment 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 moveis not a "true" move command; it actually is acopyand then adelete(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 editsfile_a. Developer 2 then movesfile_atofile_b. At this point, developer 1 commits the changes tofile_aback to the repository. The next time that developer 2 updates his view, the changes that developer 1 made tofile_awill not be reflected infile_b(since, according to subversion,file_bis a different file thanfile_a). Instead,file_awill reappear in developer 2's working copy (which is weird; if developer 2 deletedfile_a, why should subversion allow it to appear again?). When developer 2 commits the changes to the directory (including thefile_a->file_bmove), then the deletion offile_awill be committed (even though thesvn updatecausedfile_ato reappear in the directory), blowing away developer 1's changes to the repository (sincefile_bnever received those changes). This is a very broken use case; Clearcase, by contrast, has a first class move operation and correctly handles this (file_bcontinues to receive updates tofile_abefore 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
updatecommand 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 pathcreates a repository. -
svn add file_namemakesfile_name(which could be a directory name) a subversion element. -
svn mkdir directory_namecreates a directory element in the working copy. -
svn delete file_name(orsvn rm file_name) removesfile_name(which could be a directory name) in the working copy. -
xx-svn-diffwill 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 diffwill invoke xxdiff to display the differences.svn diffcan diff any two revisions against each other.-
svn diff file, wherefileis a working copy file, will show differences betweenfileand 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 withsvn diff -r BASE file. -
svn diff -r HEAD file, wherefileis a working copy file, will show the differences betweenfileand the latest revision offilein the repository.
-
- Both
svn help command_nameandsvn command_name --helpwill provide help for command_name.
