Page 152 -

A third way to share files is using svnserve tunneled over SSH. All that is required here is
that Subversion be installed on a computer that is running an SSH server. A programmer
just needs to pass the correct URL schema to svn. Subversion establishes an SSH connec-
tion and executes svnserve on the server to connect to the specified repository. Note that
this example uses the abbreviation co on the command line:

$ svn co svn+ssh://user@server/usr/local/svn/repos/hello-world/trunk/ hello-world
Password: *****
A hello-world/hello-world.c
A hello-world/hello-world.h
Checked out revision 1.
The http:// and https:// URL schemas require that an Apache server be set up to work
with Subversion using WebDAV and mod_svn. (Configuring an Apache server to support
access to a Subversion repository is beyond the scope of this book.)

The Subversion Basic Work Cycle
The authors of Version Control with Subversion (O’Reilly) recommend a basic work cycle that
programmers use on a day-to-day basis to do their work. This work cycle is described in
the script in Table 7-5.

TABLE 7-5. Subversion basic work cycle script
Name Subversion basic work cycle
Purpose Programmers use this work cycle for their day-to-day programming tasks.
Summary Subversion has numerous features and options, bells, and whistles, but most programmers
use only the most important ones in the course of a day’s work.
Work Products Input
Source code in a Subversion repository
Output
A new revision of the source code has been added to the repository.
Entry Criteria The programmer needs to modify code in the repository.
Basic Course of Events 1. Update the working copy of the code using svn update.
2. Make changes to the code by altering the files in the working copy and using svn add, svn
delete, svn move, and svn copy.
3. Examine all changes that were made using svn status and svn diff.

4. Use svn update to incorporate any changes that were made to the repository since the
working copy was checked out. Resolve changes made by other people since the working
copy was checked out by using svn resolved.
5. Commit the changes by using svn commit.
Alternative Paths 1. In Step 1, if there is no working copy yet, a new copy is checked out by using svn
checkout.
2. In Step 3, changes can be undone by using svn revert. This does not alter the repository,
only the working copy.
3. The programmer can discard all changes in the working copy by simply never committing
them to the repository and deleting the working copy.
Exit Criteria The repository is updated with the modified code.

144 CHAPTER SEVEN