One of the goals of Version Control Blog is to create summary pages with essential information about various version control systems (see left column, “Pages” section).
Here is a page on SVK.
Especially, “svk: Version Control Without Headaches” is a recommended read.
23 Nov 2007: Bazaar 0.14 has been released. Changes include tunneling to the SmartServer via HTTP, per-configuration-key policy settings, short svn-style status reports, and other improvements.
Bazzar homepage is at http://bazaar-vcs.org/.
Svk 2.0 was released on 3 Jan 2007.
Svk is the distributed version control system built on top of Subversion, with many advanced features. Svk homepage is at http://svk.bestpractical.com/.
Major changes since last major release include:
Interactive commits: svk will walk you through each change in each file, and let you decide exactly which ones you want to commit.
Views support appeared for beta testing: You can set up a “view” that is a map of several parts of a repository (different paths at different revisions). You can then check the “view” out and work with it as if it’s just an ordinary svk checkout path.
Better copy and rename support across merge.
Speed up repository synchronisation significantly.
I could never imagine I would post YouTube content on this particular blog, but I can’t resist this. A short video bashing of ClearCase by fans of AccuRev.
(thanks, VCWizard)
Xaprb takes on agile approach to version control, warning about the possibility that some non-obvious objects could sometimes be erroneously left out of it. This advice sometimes goes to the extreme, such as putting your backups under version control, but it’s a good idea to keep versioned at least init scripts, scheduled tasks and configuration files, in addition to usual code.
This article is about how to find and safeguard all the hidden code you don’t know your business relies on.
John Goerzen tells a story about his evaluation of SCM tools for the following problem:
One of my tests was a real problem: I wanted to track the Linux 2.6.16.x kernel tree, apply the Xen patches to it, and pull only specific patches (for the qla2xxx driver) from 2.6.17.x into this local branch. I wanted also to be able to upgrade to 2.6.17.x later (once Xen supports it) and have the version control system properly track which patches I already have.
3 Jan 2007: “The scripts have changed considerably since the initial announcement two months ago. The current scripts are much more reliable, and follow more of the quilt/mq semantics.”
(via LWN.net)
