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.
This book is that one place.
—, San Jose, 30 August, 2005