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.

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 you):

$ 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^[1] 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 called 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 named branches, tags, and trunk. The trunk directory should contain all of your data, while branches and 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 directory named myproject, which in turn contains your data.

Note that the original /tmp/myproject 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 the depot:

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

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.