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.
-Aaron
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