[svk-devel] Re: Mercurial (and NOT svk) chosen as Distributed SCM for OpenSolaris... Do we "Know" the reasons for rejection?

[Derek Atkins]

John Peacock <jpeacock at rowman.com> writes:

> Pazu wrote:
>> Reading the report for other tools, the fact that SVK is written in perl seems
>> to be a drawback for them. One of the requirements is "implementation
>> expertise", and the use of perl was criticized e.g. in the GIT report, and
>> although hg is written in python, the evaluator said "at least it's not perl".
>
> It also seems like they were biased towards something that acted much 
> more like TeamWare (the former internal package).  I read through some 
> of the SCM list (focusing on the mentions of SVK) and it seemed like 
> they were not happy with the speed of SVK (though they didn't bother to 
> learn that there are ways to improve that performance) and the number of 
> dependencies involved.

Being an ex-Sun employee (I left over a decade ago)..  Teamware was
interesting, and if you want to understand Teamware, just look at
Bitkeeper.  BK was effectively a re-implementation of Teamware.
BK was a true distributed SCM,  You had the full history in your
local copy, but you could push or pull or any other repository.

Honestly, all you'd need to make SVK more like that is the ability to
push/pull to/from an intermediary SVK depot.   E.g.:

    SVN <-> SVK Depot 1 <-> SVK Depot 2

The fact that SVK is all in perl is also a detractor..  It's pretty
challenging to get it installed and working.  Getting it into Fedora
Extras would be nice.

> John

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available