[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn vs svk?

From: aaron smith <beingthexemplarylists_at_gmail.com>
Date: 2007-09-11 05:39:15 CEST

Thanks, that's some good insight. I'm not going to be biased towards one or
the other. SVK has some incising features, but SVN is supported everywhere..
THanks again for the info.


On 9/10/07, Jared Hardy <jaredhardy@gmail.com> wrote:
> 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 05:36:06 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.