鳥毅的Blog

今天收到Bitbucket的通知要停止支援 Mercurial ，我在多年前Google Code還不支援Git時就提過，經過仔細比較，Git全面支援UTF-8後怎麼看都是未來的標準，在各方面都無懈可擊； Mercurial 與Git相較有明顯的效能差異，會被淘汰只是遲早的問題。 After much consideration,  we've decided to remove Mercurial support from Bitbucket Cloud and the API. Mercurial features and repositories will be officially removed from Bitbucket and its API on June 1, 2020. What used to be a very fragmented version control software market has rapidly matured. Mercurial usage on Bitbucket is steadily declining, and the percentage of new Bitbucket users choosing Mercurial has fallen to less than 1%. At the same time, Git has become the standard. According to a Stack Overflow Developer Survey, almost 90% of developers use Git, while Mercurial is the least popular version control system with only about 3% developer adoption. Given that Git has emerged as the version control system of choice for the industry, we have decided to focus our priorities and roadmap on building the best possible experience...

昨天看到 Getting Started with Git in Visual Studio and Team Foundation Service ，也就是說微軟官方將正式支援Git做為Source Control Provider。目前需要安裝 Visual Studio 2012 Update 2 CTP 2 和 Visual Studio Tools for Git 。所以我也趁機丟掉Subversion，全面投到Git的懷抱。

在Windows上設定 原本在Windows上因為中文檔名一直有問題，不敢使用 Git ，看到 Git Source Control Provider 再試中文檔名仍然不行；後來 雨蒼 告知有對岸的高手 tinyfish對msysgit做patch ，並放在Googlecode上 utf8-git-on-windows ，事情才有轉機。 原本也有考慮 Mercurial ，Windows上中文檔名雖然也有問題但是有方法修復，未採用的原因是Windows平台沒有Visual Studio provider。而且 Xcode 己經內建 Git 整合，為了自己方便當然採用 Git 才是明智之舉。（個人覺得Google Code採用水銀有點是基於對Python的偏執， 難保爾後不會有 Git 支援XD 。Update: 2011/07 Google Code支援Git了！ ）。關於Google的看法，詳見 Analysis of Git and Mercurial 。 首先當然是要安裝 patch過的git和TortoiseGit ，接著下載Apache for Windows，我是下載 httpd-2.2.19-win32-x86-openssl-0.9.8r.msi 安裝。 使用網路上最常見的 這篇 教學仍然失敗，加上 REMOTE_USER 設定還是不行，只要是用到git-http-backend.exe的檔案都出現403 Forbidden，例如HEAD、info\refs等，檔案權限已經設成everyone full access仍然有問題；後來回頭用舊方法WebDAV才搞定。 除了原本需要的alias_module、auth_basic_module、authn_file_module，還要啟用dav_module、dav_fs_module、dav_lock_module。我是沿用原來的http.conf，另外加上 extra/git.conf，在原來的http.conf最後加上 Include conf/extra/git.conf 如果要Include conf/extra/httpd-dav.conf的方式啟用WebDAV要注意httpd-dav.conf裏的DavLockDB必須要寫入權限的檔案，所以預設的目錄通常不是不存...

最近遇到好幾次 Subversion merge後在commit時發生File not found錯誤，和 這裏 一樣。 可是在 subversion Issue 1673 裏早就寫Status: Resolved, Resolution: Fixed，令我非常不滿。 原本svn之外的版本控管軟體沒有Visual Studio整合，剛才再查了一下發現 Mercurial 已經有 VisualHG 這樣的好東西可用。還有 TortoiseHG 的加持，決定再花時間測試一下，如果沒什麼大問題，應該就會報告優秀長官，以 Mercurial 取代 Subversion 。 Update：經過兩天的努力....我放棄了。 Mercurial 在Windows仍舊有中文問題，這不算是成熟的solution，只好繼續當隨call隨到的服務專員。

又是一篇個人筆記。 優秀主管帶領的優秀團隊在MCSD.Net Joseph兄的努力之下，目前已經進到coding階段，Joseph兄指導其他同仁把自己開發的模組放到branch避免干擾，但開始發現SVN令人詬病的merge問題。 由於處於開發初期，某些核心程式還不斷地更新，因此Joseph必須常更新trunk上的程式，而其他成員把trunk合併到自己的branch時常遇到問題。 以下為merge的標準步驟： 先commit自己的branch 再update自己的branch（這是因為TortoiseSVN的要求，不做不能merge） 把trunk合併到自己的branch 解決衝突 最後commit解決衝突的branch 必要時再把branch合併到trunk，方法如1~5。 講起來容易做起來難，尤其是遇到奇怪現象時需要靠經驗解決，有時候設定了svn:ignore的性質變動，會造成每次merge都有衝突，此時砍掉重練branch似乎比較快呀Orz 今天有兩位同事把TortoiseSVN從1.6.0升級到1.6.1後，合併時出現infinite depth的錯誤，個人猜測是.svn裏不知出什麼錯，也是砍掉重練才正常。 結論：終於知道為什麼gslin要把全公司的repository換成Git了。

為了協助優秀長官的計畫，先協助導入 Subversion ，我用 Apache+SSPI/NTLM整合認證 。接著要讓組員們能夠上手 svn 。要瞭解trunk/branches/tags的用法真是花了不少口水，雖然在公用磁碟有放jserv老大的優秀投影片，但同事們都趕著做案子沒看。我只能個別指導，公司找我這個時薪200元的打雜網管，有些不划算(加班就乘以1.33了呀) =_= 首先建議同事們用 TortoiseSVN ，在Windows下是首選(我自己用command line)，再配合 AnkhSVN 在Visual Studio整合使用。 TortoiseSVN 現在有版本圖，與我4年前使用時大不同，穩定性也高。相對之下， RapidSVN 就遜多了，在Linux下也會常crash，因此不予考慮。 但是問題來了，有修改目錄性質後，trunk與branch的merge常會發生衝突， TortoiseSVN 在這方面雖然有進步，但仍然不強，所以我就試一下其他的 Subversion GUI Client。 首先用的是 SmartSVN ，雖然說功能比較強，但Java的速度就比不上native的client，當然可能與 SVNKit 實作方式有關，不過時間就是金錢，等到有衝突時再來測，這方面可以參考 http://selainsoft.blogspot.com/2008/01/smartsvn-and-svnkit-javasvn.html 。 接著測 eSVN ，看來是打算和 RapidSVN 拼，但從2007年後就沒有新版看來，又是一個無疾而終的專案。再測 SubCommander ，介面有點類似 SmartSVN ，但是功能遜多了。 最後一定要提： Subversion 的working copy會自動升級，因此若使用最新版的 TortoiseSVN 後，就無法再使用 RapidSVN 、 SubCommander 等GUI，只能與 SmartSVN beta合併使用，其實會造成困擾，所以若想同時用多種client，只能用舊版的 TortoiseSVN 或 AnkhSVN 。 結論：對大部份的使用者而言，在Windows用 TortoiseSVN 是最好的選擇；若是 idea 的瘋狂愛用者，可以選擇 SmartSVN 。遇到衝突時，就call團隊裏的高手...

簡單地說明原因，公司的Subversion Repository要用NTLM認證，我在Windows上用Apache架SVN Server。 當然先下載Apache 2.2和對應Apache 2.2的Subversion，接著下載 mod_auth_sspi ，modules和bin都放好應該有的檔案後，在 httpd.conf 裏加上 LoadModule sspi_auth_module modules/mod_auth_sspi.so LoadModule dav_svn_module modules/mod_dav_svn.so LoadModule authz_svn_module modules/mod_authz_svn.so 接下來要設定權限，找到的範例要用 AuthzSVNAccessFile ，但我怎麼設定都不對，所以把Require user改成Require group，在 httpd.conf 設定如下 <Location /projectrepository> DAV svn SVNPath E:/projectrepository AuthType SSPI AuthName "Project Repository" # Require valid-user Require group "網域名\群組名" "網域名\群組2" SSPIAuth On SSPIAuthoritative On SSPIDomain 網域名 SSPIOfferBasic On # AuthzSVNAccessFile E:/projectrepository/svnaccess.txt </Location> 若有先進願提供正確的SSPI AuthzSVNAccessFile範例，不勝感激。 參考資料： http://www.wretch.cc/blog/mogula/22956644

今天浪費了兩個小時試著在Vista上使用mercurial與git，雖然程式裝起來，但hgsvn與git-svn抓取svn repository都遇到奇怪的錯誤。msysgit也不如預期，後來雖然裝起cygwin，但仍告失敗。 結論：在Windows上仍然以subversion最成熟，其他的工具仍然有待考驗。

今天有事情早回家，抽空在家裏的Ubuntu 8.04 amd64上裝了git。 sudo apt-get install git git-svn gitk qgit 用 git-svn clone [svn的url] 與hg同樣會複製repository。再來用gitk的畫面與hg view差不多，qgit則好看多了。 說實話，git與hg的速度都很快，大小似乎也差不多。目前mercurial的GUI比較多，先利用svn repository平行測試一段時間好了。

今天有事情早回家，抽空在家裏的Ubuntu 8.04 amd64上裝了mercurial。 sudo apt-get install mercurial qct hgsvn tcl tk8.5 qct 是為了要有 hgk 的功能。 但是仍然有問題，查了一下是Debian的設定檔問題，在/etc/mercurial/hgrc.d/下，把qct.rc裏 hgext.qct = 加上#註解成為 #hgext.qct = 還有hgext.rc裏 hgext.hbisect= 改成 #hgext.hbisect= 再編輯~/.hgrc，內容為 [extensions] qct=/usr/bin/qct hgk=/usr/bin/hgk 應該是找不到hgk，在 這 有，記得要chmod +x。 目前安裝 hgsvn 後已經可以匯入subversion的repository，正在測試Netbeans中... 註：Windows使用者建議裝 TortoiseHg

看了jserv老大的 「我愛 Git」簡報 後，就想換掉效率不彰的svn。 根據 Benchmarking SCMs via import linux kernel source ，再考慮到公司仍然在Widnows平台，水銀 Mercurial 似乎比git適合我，至少有比較多的GUI工具呀（而且我不喜歡cygwin的console，中文常亂碼）。 Update：gslin提到 git-svn ，想想一定也有 hgsvn ，我可以快速先試試呀！ Update：看到 Git on MSys ，又有點搖擺不定了...

在下載 OpenJDK 時無意中發現 OpenJDK 已經轉換用 Mercurial 做 版本控制 。有個很詳細的手冊在 Distributed revision control with Mercurial 。 根據手冊上 Mercurial compared with other tools ， Mercurial 針對 Subversion merge超弱這點有改進，害我也有點想跟進，有空得來看看這個 Python 寫的 版本控制 軟體。（我還不確定 Mercurial 能不能稱為 SCM ） 參考： Converting from Subversion to Mercurial

Subversion應該沒有支援Dual Repository的機制，由於平時偷懶把自己寫的幾支程式都放在同一個Repository，需要分享時就很麻煩。原本想利用Apache的虛擬目錄 Alias 的方式達成，但目前看來不可行；再使用mod_proxy的方式也有權限問題，無法達成目標。 所以我利用 Subversion 1.3版開始非正式支援 的 SVN_ASP_DOT_NET_HACK 變數，就可以在同一個目錄下有兩個不同的Repository。 The " _svn " hack is now officially supported : since some versions of ASP.NET don't allow directories beginning with dot (e.g., ".svn", the standard Subversion working copy administrative directory), the svn command line client and svnversion now treat the environment variable SVN_ASP_DOT_NET_HACK specially on Windows. If this variable is set (to any value), they will use "_svn" instead of ".svn". We recommend that all Subversion clients running on Windows take advantage of this behaviour. Note that once the environment variable is set, working copies with standard ".svn" directories will stop working, and will need to be re-checked-out to get "_svn" instead. 雖然麻煩一點，但就是在命令列切換： C:\MyAp>set S...

Subversion更新得很快，可惜Binary並未跟進，其他project如TortoiseSVN、RapidSVN也都沒有更新。 若要自己抓source下來編輯，需要不少套件，都寫在原始碼的INSTALL裏，看了一下實在是很麻煩，所以在公司我仍舊使用Subversion 1.4.0。 FreeBSD的ports已經更新到1.4.2，如果那一天公司願意改用FAPJ(FreeBSD、Apache、Postgresql、Java）開發，我就可以裝一台FreeBSD Desktop，只怕得等上100年。

很久沒看 Martin Fowler's Bliki 中文版 ，今天一看，發現最近都是好文章。 版本管理：最近快說破嘴，MIS都不肯用Subversion，無言... 更廣泛的版本管理 多台桌面電腦 讓版本管理遍地開花 Ruby： 評估Ruby http://www.martinfowler.com/bliki/ruby.html 昨天去天瓏，沒找到Ruby的中文書，只有Ruby on Rails，殘念...

Subversion 1.4 已經發行，這次升級能夠讀取所有以往的repository，所以只要放心的裝下去就可以。新功能主要是svnsync的備份工具，以及支援Berkeley DB 4.4與auto recovery。 svnsync , a new repository mirroring tool Huge working-copy performance improvements Support for BerkeleyDB 4.4 and its "auto recovery" feature Size improvements to the binary delta algorithm A handful of new command switches Many improved APIs More than 40 new bugfixes 在 Subversion 1.4 Release Notes 還有提到若dump再reload現有的repository，將會大幅縮小空間，有興趣的人不妨試試。

使用CVS（Concurrent Versions System）這個 VCS（Version Control System）將近十年，當初也是看在它跨平台而且不像VSS只能check out一份unlock。但CVS不支援rename，只能刪除新增，對於之前的版本就無法追蹤。另一個CVS的缺點是只看日期，而Subversion 是比對差異，因此CVS的許多問題不會在Subversion出現。 目前我有一部份程式是CVS與Subversion同時儲存但有些更新的問題，我打算找時間把CVS全換成Subversion，等到公司的TFS上線後，TFS專案會採用與Subversion並存的方式。