On 9/10/07, aaron smith <beingthexemplarylists@gmail.com> wrote:
> I'm looking into svk for an optional SCM, but I don't really see a
> whole lot of diferences. Some of the commands are used slightly
> different, but otherwise it's the same as SVN. Maybe some advanced
> merging features?
SVK is built on top of Subversion using an advanced series of Perl
scripts that coordinate any number of local svn repositories with
remote "mirror" repositories. Though it uses subversion extensively
under the hood, and relies on some of the same lingo, it is built as a
distributed SCM (like Mercurial), instead of a central-store type SCM
like Subversion. That makes certain actions, like checkout (mirror),
update (pull), and commit (push) very different. Interaction is more
like normal SVN when you're only updating or committing to/from a
local SVK repo branch.
> Any obvious good/bad things about SVK?
Bad:
1. SVK doesn't have lock/unlock commands. This is common to almost all
distributed SCM. You can work around this by scripting lock/unlock
requests directly to remote repositories, outside of SVK. That's what
I do.
2. SVK uses Perl, which can be hard to tweak if you're not used to it,
and doesn't compile consistently on all platforms. I have found
compiling new versions of SVK the hardest on Win32, but they're
getting better about releasing binaries for Win32 now, so that may be
less of an issue.
3. SVK is much younger than SVN, and thus less stable. It is also
built on top of SVN, so it inherits any instability that may be in the
current version of SVN -- except for the WC cache system. SVK uses a
local SVN repository as its WC cache, and most working folders are
clean of cache data.
4. SVK is not well supported by third parties (yet), and has no GUI
client to speak of (yet). The community, and thus support, around SVK
is also much smaller than SVN. This goes along with its youth,
unfortunately.
Good:
1. SVK doesn't pollute your working folders with WC cache data.
This slows down Subversion a great deal by comparison, especially
on Win32/NTFS, because exhaustive recursive folder scanning is
required for most major Subversion client commands (status, update,
commit). SVK, in contrast, just looks in the local repository for WC
cache state. Update or "pull" only requires the time for the diff to
transfer over the network, plus local disk IO time, because it is
maintained in a local mirror branch, entirely separately from working
folder state. Also, SVK allows the .svk WC cache to reside on a
separate physical disk from the working folders. This really speeds up
operations like commit and status, by allowing simultaneous disk IO in
the two data sets being compared.
For example, if a SVN WC and SVK working folder are both up to
date, an update on the SVN WC can take as long as half an hour on huge
folder hierarchies, even though nothing has changed. SVK takes a few
seconds, no matter how big the folder hierarchy is. SVK can also take
less than half the time to commit the same set of files to the same
repository, because the status comparison scan is much faster.
2. SVK allows true disconnected operation. Even if you don't use
distributed SCM methods, SVK allows you to work and commit offline,
without ANY network connection. It provides methods to get back in
sync with a central server repo any time you can get back online,
without having to retrace a lot of steps. This is the best thing about
using a distributed client with a central server.
3. SVK mirror branch operations can be separate from working folder
operations. For example, I have a local branch that mirrors the main
work repository dev branch, and a cron job that syncs the mirror any
time the workstation has been idle for at least 15 minutes, then every
15 minutes until not idle. When I "pull" to a local working branch, or
update a working folder, it only has to sync changes made within the
last 15 minutes or so, and all the data transfer after that is local
disk IO. This makes it extremely fast for day-to-day work, with
frequent update and commit cycles. My SVK updates are generally 10-50x
faster than SVN updates on the same repository, in part because the
network load is spread so thin.
I'm in the process of making my own set of wrapper scripts and GUIs
for SVK, to make it work more like Tortoise/SVN for our users -- just
a lot faster. I find the speed difference is well worth the effort.
:) Jred
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Sep 11 04:35:11 2007