Some people have trouble absorbing a new technology by reading the sort of “top down” approach provided by this book. This section is a very short introduction to SVK, and is designed to give “bottom up” learners a fighting chance. If you're one of those folks who prefers to learn by experimentation, the following demonstration will get you up and running. Along the way, we give links to the relevant chapters of this book.
If you're new to the entire concept of version control or to the “copy-modify-merge” model used by both CVS, Subversion and SVK, then you should read Chapter 2, Basic Concepts before going any further.
The following example assumes that you have svk, the SVK command-line client, and svnadmin, the administrative tool which is part of Subversion, ready to go. It also assumes you are using Subversion 1.2 or later (run svnadmin --version to check.) and SVK-1.00 or later (run svk --version to check.
SVK stores all versioned data in a depot. To begin, create
the default depot (make sure to answer
y<return> to the question svk asks
$ svk depotmap --init Repository /Users/sally/.svk/local does not exist, create? (y/n)y $ ls ~/.svk cache config local
This command creates a new directory
~/.svk which contains SVK's administrative
files, and a Subversion repository called local.
SVK has no concept of a “project”. The depot is just a virtual versioned filesystem, a large tree that can hold anything you wish. Some people prefer to store only one project in a depot, and others prefer to store multiple projects in a depot by placing them into separate directories. The merits of each approach are discussed in the section called “”. Either way, the depot only manages files and directories, so it's up to humans to interpret particular directories as “projects”.
In this example, we assume that you already have some sort
of project (a collection of files and directories) that you wish
to import into your newly created SVK depot. Begin
by organizing them into a single directory
myproject (or whatever you wish).
For reasons that will be clear later on (see
Chapter 4, Branching and Merging), your project's tree
structure should contain three top-level directories
directory should contain all of your data,
tags directories are empty:
/tmp/myproject/branches/ /tmp/myproject/tags/ /tmp/myproject/trunk/ foo.c bar.c Makefile …
Once you have your tree of data ready to go, import it into the repository with the svk import command (see the section called “svk import”):
$ svk import --message "initial import" /tmp/myproject //myproject Committed revision 1. Import path //myproject initialized. Committed revision 2. Directory /tmp/myproject imported to depotpath //myproject as revision 2.
Now the depot contains this tree of data. As mentioned
earlier, you won't see your files by directly peeking into the
depot; they're all stored within a database. But the
depot's imaginary filesystem now contains a top-level
myproject, which in turn
contains your data.
Note that the original
directory is unchanged; SVK is unaware of it. (In fact,
you can even delete that directory if you wish.) In order to
start manipulating repository data, you need to create a new
“working copy” of the data, a sort of private
workspace. Ask SVK to “check out” a working
copy of the
myproject/trunk directory in
$ svk checkout //myproject/trunk myproject Syncing //myproject/trunk(/myproject/trunk) in /Users/sally/myproject to 2. A myproject/foo.c A myproject/bar.c A myproject/Makefile …
Now you have a editable copy of part of the depot in a
new directory named
myproject. You can edit
the files in your working copy and then commit those changes
back into the depot.
Enter your working copy and edit a file's contents.
Run svk diff to see unified diff output of your changes.
Run svk commit to commit the new version of your file to the depot.
Run svk update to bring your working copy “up-to-date” with the depot.
For a full tour of all the things you can do with your working copy, read Chapter 3, Guided Tour.
At this point, you have the option of making your depot available to others over a network. See Chapter 6, Server Configuration to learn about the different sorts of server processes available and how to configure them.
 It's possible to
change the location of ~/.svk by setting the