Skip to main content

9 posts tagged with "hg"

View All Tags

· 3 min read

http://linuxtoy.org/archives/sparkleshare-beta.html

DropBox是種結合了本地和雲端，能改變使用者習慣的重要技術。

DropBox讓使用者可以用原本的形式來處理檔案和文件，只要在各種作業系統上安裝DropBox提供的軟體，登入DropBox帳號後即會在本地建立一個資料夾。 這個資料夾中的所有檔案都會自動同步到DropBox伺服器。如果你有多台設備 (電腦，iPad, 智慧手機)，並都登入了同一帳號，那麼當資料夾中的任一檔案被更新後，其他台設備很快就也能接收到這些檔案的更新。DropBox真正做到了隨處可得。

很方便的是，不管是對檔案、文件夾改名，或是刪除檔案都難不倒它。如果在其中一台刪除了檔案，其他台的檔案也會一併被刪除。為了解決客戶對誤操作的擔憂，DropBox還提供了類似蘋果電腦上的時光回溯 (Time Machine) 功能 (技術上基本就是將檔案操作結合版本控制系統)，若是做了誤操作，可以登入到DropBox網站上將上次的誤操作回復到之前狀態，真是非常安心。

另外，放在DropBox檔案夾下的檔案，除了可以像以前的作法用網芳分享給在同個網域下的朋友外，還可以直接將一個資料夾分享給其他同樣有DropBox帳號的朋友，真正是天涯若彼鄰。

SparkleShare 則是它的 open source 替代品，後端使用 GIT 版本控制系統。

PS: 大家看了我上面的介紹，可以知道我真的很愛這種東西。因為研究所時我也花過一段時間研究，並發過一篇一樣為解決多台設備間資料同步問題的 paper，而人家真的做出來了 :D

· 2 min read

傳統的版本控制系統 (Version Control System, VCS) 只有一台單一的版本庫（repository），所有的版本控制都必須經由這台版本庫主機才能管理。新一代的分散式版本控制系統 (Distributed Version Control System, DVCS) 如 git, Mercurial 則每份抓下來的 code 都可起到等同於版本庫的作用，使得在離線時做版本控制，並能容易地合併回主版本庫的工作模式成為可能。

因為分散的特性，也衍生出各種可能的合作模式。 git 有 A successful Git branching model，Mercurial 有 Workflows: Branch As Needed, Stable & Default, Translation Branches 等方式。

實際上該採用哪種方式比較好？先看看其他人怎麼做，從中選擇，或是加點創意，找出適合自己團隊使用的方法吧。

· 5 min read

Mercurial(Hg) 一直是我很愛用的版本控制工具。以前自己最常用的用途是拿來取代 svn，單純享受單機 / 離線使用版本控制系統開發的樂趣。

要單機使用版本控制系統開發，照著水銀分散式版本控制系統的使用概念做就行了。

最近看了Hg init和ProGit兩份分別講 Hg 和 Git 分散式版本控制的書，裡面都相當推崇「分支 (Branch) 開發」的概念。 所謂「分支開發」，就是將主幹 (trunk) 保持在穩定可運作的版本（雖然本來就該這麼做），在開發任何新功能時都另建新分支 (branch)，開發到一段落之後再合併回主幹。能支援這樣的開發模式，是因為 Hg 或 Git 這些分散式版本控制系統做開分支、合併等動作的額外開銷都很低。

那麼要實際使用時該怎麼做呢？

開分支

我有一個名為「ZAKU」（薩克）的目錄，主幹版本代號為 3, 現在要實作一個將綠色變成紅色的功能，這時我們可以建立一個新分支來繼續開發這個新功能。分支命令的格式為：

> $ hg branch [branch name]

因此要建立一個名為「red」的分支，可以使用以下命令：

> $ hg branch red
> marked working directory as branch red

這麼一來，之後 commit 的 code 都會進入「red」這個分支了。

查看狀態

在 commit 進一些 code 之後（版本代號到 13），輸入「hg branchs」命令可以列出所有版本

> $ hg branches
> default                       3:e2287f9031a1 (inactive)
> red                           13:e590de4b0dc9

切換分支

在開發新功能的同時，也可能會碰上整個專案共通的 bug，以前老派的作法是再 check out 一份主幹的程式碼，然後兩邊修正，現在有了 hg, 只要先暫時切換回主幹，把 bug 修正了再合併回分支（或到時一次把分支合併回主幹）。

要切換回主幹，輸入「hg update default」即可。

> $ hg up default
> 4 files 已更新, 0 files 已合併, 3 files 已移除, 0 files unresolved

合併

當我們把「red」分支中的新功能做好後，可以很容易地將這些修改合併回主幹。

首先，用上面的方法切換回主幹，然後輸入「hg merge red」，即可將「red」分支中的修改加進主幹。

> $ hg merge red
> 5 files 已更新, 0 files 已合併, 0 files 已移除, 0 files unresolved
> (branch merge, don't forget to commit)

合併命令的格式為

hg merge [branch name] 合併完後確認沒問題，就將程式碼再 commit 進版本庫吧！

如果只想 push 某 branch 的修改到版本庫，可以使用

hg push --rev [version] 命令，這樣只會將與指定版本相關的修改上傳到版本庫。

One more thing

同樣的方法，我們可以再建立一個分支「horn」來開發長角的功能，然後再將「horn」分支合併回主幹。

別忘了 hg 還有提供一個離線網頁瀏覽功能，輸入「hg serve -p 5000」，在瀏覽器上輸入「http://localhost:5000」就能看到類似 gitweb 的版本控制訊息網頁。點選左側的「graph」標籤，可以用視覺化的方式看到之前所有分支合併的圖形記錄囉！

學會分支與合併後，你的開發效率會不會也變成三倍速哩？

參考資料:

· One min read

在做完「hg clone」（就如同從 Server 端 Check Out 程式碼）後，除了可以對原 Server 做「hg pull」以更新程式碼之外，也可以多加別台 Server 進列表。

如原來從 Alice 處「hg clone」下來原始碼，而現在也想要從 Bob 處直接取得他的更新，可以使用

$ hg pull [bob server]命令。

另一個好方法是可以在 .hg/hgrc 中定義額外的 Server 別名 (alias)。

例如原來的 .hg/hgrc 長這樣:

[paths] default = [Alice Server]/[project] 我們在其後加入 Bob Server 的別名如下: [paths] default = [Alice Server]/[project] bob = [Bob server]/[project] 儲存後，要再從 Bob 處直接取得他的更新，可以使用 $ hg pull bob 命令來直接取得 bob 的原始碼。分散式版本控制是不是很方便呢 :)