Benchmarking SCMs via import linux kernel source.

Maybe someone would interested, so I posted the results here:

(Benchmarking on a p4 3.4G SMP debian stable-etch, 2giga ram machine, all SCM software use packages from debian stable, checkout/branch occurs on localhost)

conclude:

initial speed: hg==git(3Min) >> bzr(15Min) >> svn(71Min)

checkout/clone speed: hg == git(3Min) >> svn(11Min) >> bzr(21Min)

space effiency: hg==git(123Mb) >> bzr (230Mb) >> svn(repo:82Mb+workingdir:573Mb = 655Mb)

== report ==

hg:
/usr/bin/time -o ../hginit.usage hg init
/usr/bin/time -o ../hgadd.usage hg add .
/usr/bin/time -o ../hgcommit.usage hg commit -m "first import"


real 3m25.284s
user 0m34.130s
sys 0m4.868s

git:
/usr/bin/time -o ../gitinit.usage git init-db
/usr/bin/time -o ../gitadd.usage git add .
/usr/bin/time -o ../gitcommit.usage git commit -m "first import"


real 3m20.346s
user 0m23.061s
sys 0m5.032s


bzr:
/usr/bin/time -o ../bzrinit.usage bzr init
/usr/bin/time -o ../bzradd.usage bzr add .
/usr/bin/time -o ../bzrcommit.usage bzr commit -m "first import"

real 15m10.689s
user 1m59.299s
sys 0m9.617s

svn:
svnadmin create --fs-type fsfs /home/tim/test/testsvnrepo/
svn import -m "New import" linux-2.6-2.6.18.dfsg.1 file:///home/tim/test/testsvnrepo/


real 71m3.704s
user 0m53.467s
sys 0m24.998s

#### Checkout/Branch(Clone) time ####


#time bzr clone linux-2.6-2.6.18.dfsg.1/ testbzrclone
Branched 1 revision(s).

real 21m5.351s
user 1m38.898s
sys 0m11.465s

# time hg clone linux-2.6-2.6.18.dfsg.1/ testhgclone
20690 files updated, 0 files merged, 0 files removed, 0 files unresolved

real 3m15.951s
user 0m12.449s
sys 0m4.016s

#time git-clone linux-2.6-2.6.18.dfsg.1 testgitclone
remote: Generating pack...
remote: Done counting 21351 objects.
remote: Deltifying 21351 objects.
remote: 100% (21351/21351) done
Indexing 21351 objects.
remote: Total 21351, written 21351 (delta 2213), reused 0 (delta 0)
100% (21351/21351) done
Resolving 2213 deltas.
100% (2213/2213) done
Checking files out...
100% (20323/20323) done

real 3m27.516s
user 0m59.908s
sys 0m5.132s

#time svn co file:///home/tim/test/testsvnrepo/ testsvnco
Checked out revision 1.

real 11m44.980s
user 0m35.294s
sys 0m15.849s


####SPACE USAGE ####

123M linux-2.6-2.6.18.dfsg.1/.hg
123M linux-2.6-2.6.18.dfsg.1/.git
230M linux-2.6-2.6.18.dfsg.1/.bzr
82M testsvnrepo
573M testsvnco


Note: I've installed bzr 0.18, and results shows no big difference.

[link] Mark Shuttleworth on VCS. 馬克·沙特爾沃思先生談論版本控制系統

馬克·沙特爾沃思(Mark Shuttleworth)先生 -- 如果你不知道我在講誰的話....

就是世界第二位平民太空人,早期debian開發者跟Ubuntu創辦人啦...

在他的blog上談論了他對VCS的一系列看法.

Choose Lossless VCS tools if you have the luxury

Further thoughts on version control

Renaming is the killer app of distributed version control

我讀了一下他的觀點大概就像這樣...

"""
VCS最重要的功能就是renaming, 而bzr把renaming視為非常重要的功能,
不管你的目錄怎麼搬, branch怎麼merge, bzr就是玩不爛.

bzr就像raw-format, 什麼都紀錄所以速度較慢但是卻可以無損轉換成其他格式...
在不同的情形不同的狀況下, 都可能有不同的最佳VCS工具.
何況世界變化很快, 從tarball, RCS到CVS到SVN...
現在很明顯的又進入到了分散式VCS的戰國時代,
而過一陣子搞不好又有更新更好的工具.

所以... 就像你最寶貝的片子/照片(通常)會存個無損RAW檔一樣,
bzr什麼都給你記下來, 當你真的需要在特定環境作特定應用而bzr辦不到的時候,
可以很快轉換過去.

"""

當然底下的評論自然有darcs眾,水銀黨(hg)跟git幫要戰mark...
這個就跟我沒關係了...
我只是普通用戶一枚,
反正這個系列的文章可能還會繼續下去,
就等著隔山觀虎鬥, 爆米花買好, 戰的好記得出來拍手就好了.... XD

Mozilla "moves" to python-based DSCM: mercurial to replace CVS

Version Control System Shootout Redux Redux

"""
It's important to realize the headline here isn't "Mozilla Project picks Mercurial for Next Generation Version Control System." It's "Mozilla Project moves to Next Generation Version Control System."
"""

根據引用文章的說明, 不是pick而是move :D (註：原文在這邊要表示的意思是bzr跟hg都是很好的系統, 所以Mozilla不是選了hg而是移向下一代的版本控制系統)



我不是標題黨, 不過Mozilla的確要改變原本使用CVS的方式,
改採現正流行的distributed SCM (DSCM, Distributed Software Configuration Management 話說現在每次只要寫縮寫不打全文就會被某人唸, XD ) ,
而選中的正是由python實作的: mercurial.

由該文引用的這張被kuso過的真人快打系統圖中,
可看出下面這幾種是曾經在mozilla會議中提出來討論過的:
rcs,mecurial,cvs,svn,svk,bazaar,arch,bitkeeper,sourcesafe,clearcase,Perforce,git.

根據該文的說法, 有被認真考慮過的只有底下4個: bazaar / mercurial / git / Monotone
git跟Monotone也很快就因為win32 client支援程度不好的問題被ruleout.
(比較意外的是非常先進但使用haskell實作的darcs似乎完全沒有被考量. 不過根據該篇文章的一篇評論,似乎有人在開始匯入時就out of memory了.)

因此很快的, 剩下兩個均由python實作(也意味著跨平台應該非常好 :D)的DSCM mercurial/bazaar就被mozilla同時考慮了.

mercurial(以下簡稱hg)跟bazaar(以下簡稱bzr),是兩個性質非常類似的DSCM, 基本上兩個幾乎可以等同看待, 操作命令也幾乎一模一樣, 就我個人非常淺薄的使用體會跟認知,bzr功能略強一些, 而hg速度快上不少.
我個人使用的是bzr, 所以其實就私心來說是希望bzr能被mozilla採用的. 很可惜的, 根據這篇文章的說明, mozilla也很想採用bzr, 但是發現匯入mozilla cvs庫卻需要用上一個月 :P (使用的是0.14/最新的0.15已經試圖想解決performance問題) 相反的採用hg就只有7天.

不論如何mozilla似乎已經要決定轉換到hg了,
去年shawn跟我提過的hg現在果然是紅了,
曾經有一次開玩笑的跟yungyuc在線上聊天聊到如果那天bzr停止發展了那我大概就會在hg的船上. 沒想到這麼快機會就來了 XD 不過事實上bzr還在積極發展並改善速度加上也可以使用hg的repos,且又由於我的檔案大部分都不大, 加上binary file都還在100MB以內, 倒是還沒遇到太多效能上的問題. 也許哪天真的有需要也可改用hg,暫時我將還是使用bzr為主. 不過大家在選用時可以將hg列入考慮. 另外該篇文章也提到:
"""
There was a lot of support in the project for both tools, and I personally know that the Bazaar developers spent a bunch of their 0.15 development time working on some of the performance issues we ran into. The great thing about these "nextgen" version control systems is that they all track the information necessary to re-create history. Because of this, switching between systems is much eaier, and in some cases, using your favorite system is possible (bzr, for instance, can pull directly from Mercurial).
"""
所以我認為至少在這短時間內, 這兩者都是非常好的選擇. :)

底下列出目前使用hg跟bzr的知名opensource專案, 僅供參考:

hg:
Mozilla,opensolaris,ALSA,mutt.Xen,MoinMoin,e2fsprogs. (gpl-sun-java is considering hg too)

bzr:
Ubuntu, Drupal,BitlBee,nose,PyChart,Samba.

(當然, 更大部分的專案都使用svn 事實上我也很愛用svn 只要svn符合你的需求,svn目前還是非常正確的選擇, and, Nobody ever got fired for picking IBM :^)