Foreword

After playing with Subversion and SVK for a long time,
without really being able to use either for real work since our
main repository was still using CVS, the author convinced his
management to let him switch their SCM over to SVK directly
instead of moving to Subversion which would have been at best a
step sideways from CVS.

The transistion went smoothly and after the CVS repository
was converted to Subversion using cvs2svn, we mirrored it to a
SVK depot and setup a quick and easy bootstrap proccess for
everyone to use. Almost all of the developers started using SVK
immediately without any problems. A few of them asked the
question:

Q: You expect me to use a piece of software without
documentation for mission critical work?

A: It has documentation, look at the built in help or go
to the svk wiki.

Of course I started to realize that without hanging out in
the #svk irc channel, the help and the wiki were really not
sufficient to help get someone going in using SVK. So I started
writing a guide to using SVK day by day on our internal
wiki.

After a few days of manually updating the wiki and keeping
the table of contents in sync with the actual content, I
started to realize that a wiki isn't the best way to write a
book, which is what this guide was turning into. I also watched
people coming to #svk on a daily basis asking very similar
questions about SVK which should have been answered in a
document somewhere.

After some encouragement from clkao in irc I decided to
start with a copy of the Subversion book's docbook XML sources
and write a book about SVK. The idea was to collect information
from the wiki, FAQs, from #svk and things I was putting on our
internal wiki that really applied to SVK in general into one
place.