HTC工程師：「HTC 全系列手機不能分享 wifi 網路給電腦使用」!!!???

當我的 wildfire 升級至 1.27.709.3 後，原本可以作到的事(將 wifi 網路分享給 NB 使用)居然不能作了。

閱讀更多…

完成 2010 台東之美 51.5K 鐵人三項賽

總排名： 675(完賽人數為 740)
組別： M30
分組名次： 130(分組完賽人數為 141)
總成績： 04:01:44.57
游泳： 01:05:58.12(時限 50 分鐘)
自由車： 01:43:03.47(時限 100 分鐘)
路跑： 01:12:42.98(時限 80 分鐘)

View all

Get your own

三項運動中，主要還是游泳最弱。不但比標準時間多了十六分鐘，也讓我在比自由車時，多花了點時間在休息，而這段時間都算在自由車比賽當中。

雖然成績差強人意，不過，這是第一次參加三鐵賽，原本的目標就是「完賽」而已，所以當我從活水湖起來時，感到十分興奮，因為我從來沒有在游泳池中一次游上 1500 公尺。在比賽的前三天，最佳紀錄不過是一次游 300 公尺而已。

何況在活水湖中游泳的路線並不是直的，必定比 1500 公尺更長。但在比賽中，我完全沒有在魚雷浮標上休息過，真的是一口氣游完。

事實上，在比賽前一日的試游中，我變得有點怕水，因為這是第一次在開放水域(踩不到底)中游泳，覺得非常可怕，尤其是第一次下水時，完全是出乎意料的狀態，我不知道活水湖是有階梯可以走下去的，當我從岸邊準備下水時，所踩的地方是斜坡，所以走著走著我就滑下去了，想走回斜坡，可是它上面長滿了青苔，根本走不上去，接著就漂離岸邊了。這時都還沒戴上蛙鏡及泳帽呢! 根本就不會游泳。

還好有背了魚雷浮標，趕快趴在上面休息，然後戴上蛙鏡及泳帽。待心情平復一點後，開始試游了幾公尺，不過覺得怎麼游都游不太動，所以先回到岸邊，這時才發現兩側是有階梯可以走上去的。走上階梯後，在岸邊休息了幾分鐘，剛好有其他有經驗的參賽者，跟我說到「從剛剛的游泳姿勢中，我的浮力還不錯，放輕鬆游就行了」。於是在休息了幾分鐘後，又下水了，這次是有準備的，所以大約游了 20 公尺，在看到離岸邊很遠後，我實在不敢再游下去，所以就游回岸上，經過這二次的試游，我的雙腳還在不停的發抖，真的是被嚇到了。比賽前一晚，我的心情都是在擔心隔日的游泳，我到底能不能完成???

真的到游泳比賽時，男人的面子問題對我真的是太重要了，實在不想作那個被救生員撈起來的人，於是說服自己，可以游的慢一點，但是一定要游完，這種心態讓我渡過這 1500 公尺的考驗。

到了自由車比賽時，這算是我比較擅長的部份，所以在這個時候，我大概超了 40 個人的車，只被 1 個人超過去。

在自由車比賽部份，我將它界定成「為路跑準備」，所以出發前我就吃了一根香蕉，而在這段路上，我也吃一份補給品及整罐水。這種補給計畫是因為我在今年暑假時，就有先來這邊試騎，然後發現我不在路上吃補給品的話，在後面的 10 公里根本就沒有力氣騎完所制定的。

不過，在這次比賽中，我吃得太多了。在路跑前，我又在自由車的車棚中，吃了一份補給品及喝了一些寶礦力，結果，在路跑時，我覺得肚子跟著振動，而且有點痛，在走了 2 公里後，才開始慢慢地起跑。跑步時，也發現我的右小腿及膝蓋有點痛，真的是太操勞它們了。不過，耐著痛，還是慢慢地跑完了。最後拿到人生第一面的完賽獎牌。



這次比賽中，除了我很累之外，老婆也很累，在游泳時，她得一直在岸邊注意我有沒有溺水，要不要叫救生員。就這樣，也跟著我走了一個多小時。老婆，辛苦妳了。

工程施工項目預算編列

本文與台北花博爭議有間接關係，當然不是因為我要為郝龍斌說話，也不是要撻伐他。只是純粹就「工程施工項目編算編列」這個讓大家都有話說的爭議問題來提供我的所學。

基本上，我對整個花風暴的資訊掌握的不如他們局內人了解，所以，我只是分享我在「營建管理」這個學科所學到的東西。

常收看這個 blog 的朋友們，或許會認為我學的是資訊方面的學科，畢竟我發的文多半是 python, google app engine, mercurial, django 相關的文章，不過，我可是道道地地的土木系學生，從大學、研究所，一直到現在的營建管理博士班。

一個傳統的土木系學生主要有幾種專長可以選擇： 結構、大地、水利、測量、運輸、建築、環工、營建管理(奇怪我記得應該有九項的，到底少了那一項?)，其中建築、環工、運輸多半早已分家，而水利、測量、營建管理則視學校發展方向而有所不同，像中興土木就包含了結構、大地、水利、測量、營建管理，但逢甲土木就只有結構、大地、測量、營建管理。

而這次大家吵得十分火熱的話題，也就是營建管理學生應當了解的課題： 工程預算編列。

一個營建專案的生命周期有五個階段： 規劃構想(業主)、設計(工程顧問/建築師)、發包(業主)、施工(營造廠)、保固營運(管理公司/業主)。由業主針對本身需求提出構想，委託顧問公司設計，確認施工圖說後，由業主招開發標程序依「最有利標」或「最低價標」方式委託營造廠商施工，在施工階段，由監造單位(業主/工程顧問/建築師)負責監督施工品質及工期，待驗收合格後，由廠商向業主請款，通常會保留 10% 工程款，作為保固工作之保證，最後再交由業主或管理公司管理最終產品(大樓、橋梁、道路…)。

一個項目單價編列會有三個單位接觸到這件事： 業主、設計公司、營造廠。這也就是工信為什麼會在報上刊登聲明稿，請台北市政府說明為何不採用工信編列之項目單價，而是使用自己編列的預算書。而這份市政府決定的預算書現在卻被叮得滿頭包。

再回到生命周期五個階段，這次聚焦在預算編列上，業主在規劃構想階段中，首先要先拿到錢，如果是公家機關，它們可能是從上級單位那邊拿到錢，然後要針對某種計劃，給予它特定金額，而這個計畫下又會分好幾種工程，這些工程主要是呼應所屬計畫的目的，如中央政府提出八年八百億要治水，它就會拿一筆錢給水利署，而水利署也會提出幾個計畫來達到治水目標，像是易淹水計畫…等，而這個易淹水計畫中，轄下再分成幾個工程，而這幾個工程就會交由水利署工程專業人員主導，把錢花掉，來換回工程設施，就公共工程預算分配課題可詳讀我學弟的論文來了解。

工程專業人員在拿到工程預算後，就會委託設計單位，或自行設計工程的施工圖說，並撰寫分標計畫書、施工綱要計畫書、工程數量概算書…等。這個工程的建造金額在設計後，發現其小於預算金額，則會回沖到所屬計畫中由其他工程支領，若不足則反之，又或者直接刪減設計。而這個建造金額是怎麼來的，就是在施工圖說中，由設計單位作了工料分析，統計出要多少材料(鋼筋、混凝土、模版)、多少人工(鋼筋綁紮工、模版工)的數量，再乘以各項單價得之。

這個規劃總價與實際建造金額真的相等嗎? 不可能!!!

在規劃總價中，通常工料分析的數量是不準的，而且單價也是不準的。數量不準其原因是，設計單位在設計階段，是否能得到施工現地的詳細資訊，如基地高程、地質報告、水流速度、流量…等，以基地高程來說，若取得點不夠多，則其他位置就必須用內插法代換，當然也可以使用航空測量，不過飛機一起飛就要 40 萬(之前聽說的，不知行情有沒有變)。詳細的資訊是得用錢去換來的。那基地高程數據不準確，在整地時就會造成挖填不平衡 *1，像土方量過多的話，原本設計上沒有棄土作業，結果在實際整地上，就會出現棄土作業，數量從 0 變成 N 。

* 註1 挖填平衡，是指在整地作業上，要將原本過高的基地經過機具的開挖把土方運至過低的基地填入，而通常我們希望在一個建造基地中，挖方量是等於填方量的，這樣我們就不需要從外地運入土方，或是將本地土方運至外地。可減少運輸成本及環境汙染成本。

那單價不準的原因在於時間因素及供應商因素兩種。在規劃工程到實際建造工程中間，短則半年，長則 10 年(像是水壩、高鐵)，這麼長的時間，都可以讓鋼筋從一噸 9 千漲到 4 萬，再跌到 1 萬 4 了，那你還會覺得單價準有必要嗎? OK，我舉的例子太極端了，設計單位也的確不能因工期長，就亂訂單價，他們還是得自行訪價，自行訪價大致有三種方法： 機關內部訂價、電訪供應商、營建物價(工商廣告： 這是我學長負責的，乃國內第一名的專業營建物價報告)。

• 機關內部訂價： 依過去工程經驗，明定工料價格，提供內部人員編列預算之用。其缺點為機關內部資料不夠豐富，還是有工料會沒有明確訂價。


• 電訪供應商： 從供應商那邊得到報價資訊。其缺點為一個施工項目要打三通電話(如果你都有這些供應商的電話)的話，一個工程若有 3000 個項目，你覺得設計單位會乖乖每個項目都認真訪價嗎? 而且你問的供應商，也不是實際營造廠所配合的供應商，那設計單價真的能符合施工單價嗎?


• 營建物價： 因應「機關內部訂價」不夠豐富，而「電訪供應商」又麻煩且不具公正性，所以營建研究院對國內的設計單位提供「營建物價」資訊，由他們幫你打電話，而且不只問 3 家，提供高達 4000 項的常見營建工料價格資訊。

如果「營建物價」都已提供價格資訊了，那這次花博相關工程直接套用，不就行了。何必自己生單價數據呢? 原因在於「營建物價」是包山包海，不過它還是沒包到宇宙呀! 我相信，這次花博的「馬蘭花」、「龍吐珠」的報價資訊，它一定沒有，所以這二項報價又回到使用「電訪」方式。

看到這裡，你會不會覺得公共工程的錢，好像花得不踏實，居然在設計時，沒有一個公正且明確的項目單價分析表來決定出工程真正的成本價，然而這就是營建專案的特性：規模大、項目雜、工期長所造成的。無法明確定出成本價也沒有關係，因為到時候成本價也會被營造廠商的投標價所修改，且通常是往下修改。

當設計單位決定施工圖說後，業主就會進行發包招標程序，採用最有利標或是最低標方式發包。在最低標中，營造廠商只提供一個工程總價，只要它的工程總價比其他在場的營造廠商低，它就得標了。而得標後，業主與營造廠商就會簽約，約定該工程各項施工細節，而其中，就重要的是「單價分析表」，這個單價分析表乃紀錄該工程有多少施工項目，每個施工項目的施作數量，及施工項目的單價。

前述所提之單價分析表，除了設計單位要製作，營造廠商也會製作一套內部的單價分析表。

營造廠商在提出投標總價前，它會作幾件事，將招標的施工圖說拿來分析，研究設計單位提供的各項現地測量、實驗報告，得到自己一套的工料數量，再透過供應商報價或「營建物價」刊物決定每個項目的單價，再加上可接受的利潤成數，這樣就能得到一個「營造總價金額」，如果以這個「營造總價金額」去投標，且幸運得標後。業主與營造廠商就會協調(合併)出一套契約項目單價分析表，把雙方自己分析的表合併成一張。並依照這張契約項目單價分析表，作為廠商請款依據。

契約項目單價分析表的合併有二個限制，一、契約項目的總價就是廠商的得標價，這也就是工信在聲明稿中第二點所強調的『本工程契約除訂約總價與決標總價相同之外，契約個別項目單價是依據政府機關的預算而來，與本公司實際投標單價並不相同。』，這是其來有自的呀!; 二、契約項目的施工數量必須依照業主招標文件，就算業主認定該工程沒有棄土作業，但營造廠商評估一定會多餘土方要棄土而且是營造廠商考量正確，也必須依照業主招標文件。所以在這兩者的限制下，惟有調整各項契約的單價方可滿足。

從這裡看來，就可以知道項目單價是不可能與實際市價相符的。有可能因為設計單位認定的數量計算過低，所以單價必須往上調，也有可能是營造廠商以超低價搶標，造成單價往下調。所以當你提出某個項目單價去評估它與市價有所差別，這都是不盡合理的。

在合併契約項目單價分析表上，營造廠商會提出一套，而業主也會提出一套，但通常是採用業主的。為什麼? 因為出錢的人最大。另一方面，也因為從調整單價數據上，可能會讓營造廠商有超額利潤，或是增加工程無法完工的風險。

契約項目單價分析表是廠商計價的依據，對廠商而言，它一定希望將較早施工的項目單價調高一點(這個動作一定會讓較晚施工的項目單價變低，因為「總價不變」的限制)，這樣它在早期施工時，可得到超額利潤，雖然在晚期施工時，它會是賠錢施工的，不過，這部份的成本早在之前就領到了。我們來看看下面這個簡單例子。

業主編定的XXX工程契約項目如下:
    A工項: 設計數量 1000 ，施工開始日 1 ，施工完成日 10 ，單價 100 元
    B工項: 設計數量 1000 ，施工開始日 6 ，施工完成日 15 ，單價 450 元
    C工項: 設計數量 1000 ，施工開始日 16 ，施工完成日 30 ，單價 350 元
    廠商利潤: 設計數量 1 ，施工開始日 1 ，施工完成日 30 ，單價 100 元

營造廠商編定的XXX工程契約項目如下:
    A工項: 設計數量 1000 ，施工開始日 1 ，施工完成日 10 ，單價 800 元
    B工項: 設計數量 1000 ，施工開始日 6 ，施工完成日 15 ，單價 50 元
    C工項: 設計數量 1000 ，施工開始日 16 ，施工完成日 30 ，單價 50 元
    廠商利潤: 設計數量 1 ，施工開始日 1 ，施工完成日 30 ，單價 100 元

由業主的單價分析表來看，可繪製下圖的藍線，而廠商的則是繪出紅線。



上圖是預定進度曲線，橫軸是工作日，縱軸是進度百分比。因為每個項目都有先後施工依據，所以每張單價分析表，都可以繪出這條曲線，而這條曲線往往是 S 型的，所以又稱 S curve 。

在上圖中，我們假設藍線是真實世界的預定進度曲線，但契約項目單價分析表卻是簽紅線版本的話，這代表廠商得到了紅線減藍線面積的現金流量利息，這是對「有良心」廠商的超額利潤。又或者遇到的是「沒良心」的廠商，它會在第 10 日請款，並在一領到錢後馬上倒閉，這樣它會領到 86% - 8.6%(保固保證金) - 10%(期初繳交的履約保證金) = 67.4% 的價款，但此時，它卻只支付 37% 的貨款，而且還有可能都是開票的，所以它實際上可得到大於 30.4% 的差價。

所以呀! 本來業主就不會相信廠商提出的單價分析表，而是會自己生一套。

而業主在調整契約項目單價分析表上，如果只是單純就以得標價與預算金額作等比例的調整，那還簡單。如藍線版本，是招標時的單價分析表，而實際開標後，廠商以 92 折得標，那一律把單價乘以 92 折不就結了。如果世界這麼簡單美好，那很多人就沒有工作了。

一個工程的契約項目從 300 個到幾萬個都有可能，而有些工項是固定費用，如工程保險、試驗費用，有些工項是其他工項的等比例金額，如廠商利潤、營業稅，有些工項在未來又可能遇到變更設計，需要增減數量，如果現在的單價調整的不合理，等到變更設計時，大家就會吵翻天。所以就單價調整工作本身來說，它本來就不是一件簡單的事，這部份可詳讀蔡昇穎的「工程採購標價審查與合約單價調整機制之研究」一文。

簡單講，如果該工程在簽定契約項目單價分析表後，並沒有變更設計(增減施工數量)，且工程品質完全通過監造要求，並依約完工的話，契約項目單價分析表訂得隨便一點也不會有爭議，一朵蘭花要訂 200 元或是 2000 萬都沒關係，因為工程總價就是標價，差別只是廠商多領點利息或是少領點利息而已。

但如果有變更設計的話，那單價有沒有按照市價就很重要了，因為變更設計的數量，會對總工程款造成爭議。像是原本簽訂 1 朵蘭花單價 1000 萬，結果市政府覺得原先規劃的 10 朵蘭花太少了，要求再增加 10 朵，這樣工程款就會暴增 1 億，這樣合理嗎? 又或者反過來說，市政府後來覺得這次花博應該展示較稀有的花卉，所以就不展示蘭花了，在變更設計後，會讓整個工程款少 1 億，你覺得營造廠商作得下去嗎?

結論：

1. 無法期待一個幾年後才完工的工程，在規劃設計時就明確定出它的工料數量。


2. 只單看幾個施工項目的單價是不盡情理的。


3. 變更設計時，施工項目的單價才重要。


4. 施工項目訪價時，要善用「營建物價」(再一次工商廣告)

以上是我對契約項目單價分析表相關資訊的分享，然而這內容畢竟是我參與政府機關計畫案中，從部份公務員口中聽來的，再混合課本所學，所以並不全面，且我本身尚無任何工程實務經驗，如果有所闕漏錯誤，懇請指教。

我們該痛恨投資客嗎?

從以下這些文章中，我們可以了解台灣想買房子的人目前對「房產投資客」極度地不友善。

http://blogs.myoops.org/lucifer.php/2010/10/05/housewuwu
http://www.wretch.cc/blog/oolong1001/5641402

然而這想法對嗎? 或許是我已經買了房子，所以想法才會與其他人不同! 但照邏輯推導，還沒買房子的人要歡迎投資客才是，而且是愈多投資客去推升房價對沒買房子的人是愈有利。

Why!?

首先分清楚投資財與消費財的差別，投資財對擁有者而言，只是單純的金錢效用，擁有者的目標就是以最少的價格買進投資財，並以最高的價格賣出。但消費財就不是單以金錢論之的，擁有者視消費財含有其他不同金錢的效用，如： 飽食、製造、炫燿、管理權力等。

以股票作例子，買進 1 張巨大(9921)，如果視之為投資財，則購買者一定希望以最低價格購買，並在持有後，每年領取最多股息，期末並以最高價格賣出。簡單講，它的內部報酬率(IRR)愈高，對購買者的效用就愈高。

但如果是把巨大股票當消費財，就不一定了。若購買者對掌握巨大公司有高於一般人的需求，他想要持股達到 5 成以上並擔任董事長，那他可能會進行收購，這時候，我們就不能以 IRR 來分析它的買進價格了，因為這與購買者在擁有巨大後的作為有關。而其他像汔車、金飾以及 3C 產品，也都是消費財的一種，擁有它們的人，並不在乎買進後，該產品的市價波動。

房產與股票類似，對某些人而言，它是投資財; 對另外的人而言，它是消費財。

本文主要討論從消費者(將房產視為消費財的人)角度，來看待投資客(也就是將房產視為投資財的人)的態度應當如何!

從目前的現象看來，投資客對房產的價格推升是有影響的，然而只看到推升情形，就跳出來大肆批評投資客，我個人是覺得有點短視。投資買賣是一種中性行為，「買入」後一定要「賣出」才會有獲利(若不考慮股息及租金收入)，這些投資客現在拼命買房產造成價格推升，但總有一天，他們也要賣出的，這時候一定會造成價格下跌，當這現象發生時，消費者你還要痛恨投資客嗎?

若只考慮投資客以本金買賣房產來看，它對價格應是中性的，但考慮了外部性，就會發現，以長期而言，投資客會導致拉低房產價格。一、因為房價大幅上漲，所以很多建商開始搶建，想想農產品的例子，前年香蕉價格好，今年通常賤如屎，如果房價漲得不夠多，就吸引不了建商們的興趣; 二、因為房價短時間大幅上漲會讓投資客認為錢好賺，所以他們借錢來買的機率會變高(因為錢好賺，就不會在乎利率了)，借愈多買愈多，等到房價反轉時，就可以看到一堆法拍屋了。到時候，就變成買方市場。

簡單講，如果投資客真能不斷控制市場價格上揚，那日本股市現在不只 3 萬了，而美國兩年前不會發生次貸風暴，台灣的營建上市公司不會有人下市。

消費者一生通常只會買一棟房子，別讓自己陷入這一小時段中，把眼光放遠一點，或是說有耐心一點。只要活得夠久，你會發現，房價就是在那邊上上下下的。千萬不要相信：「台灣土地就那麼多，未來會不夠用」這種屁話。

所以站在消費者的立場上，應該要歡迎投資客入市，然後消費者要忍耐購買的慾望，等到他們玩完你丟我撿的遊戲膩了後，消費者一定可以買到更便宜的房子，而且在玩「你丟我撿」的遊戲中，消費者的平均租金還會往下降的。

這樣子，你還要痛恨投資客嗎!

使用 Google AJAX Libraries API 時，無法離線撰寫網頁程式?

在網頁程式中，我都是使用 Google AJAX Libraries API 來 host jquery 程式庫的，然而這麼作有一個缺點，如果你是在離線作程式設計時，要手動修改樣版，把 Google 來源的 js 檔改成從本機讀取，是有點麻煩，但致少作得到。

但若是將來在系統上線後，使用者上得了你寫的網頁系統，卻無法連至 www.google.com 呢? 那怎麼辦，雖然這個機率會滿低的，但也是有可能會發生在這個網頁系統屬公司內部系統，而對外連線卻被中斷的情況下。

別怕! 很簡單，下面就是一個範例，第 6、7、8 行改成本機 host 的檔即可。

 1 <link rel="stylesheet" title="default" type="text/css" media="screen" href="http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/themes/smoothness/jquery-ui.css"> 2 <script type="text/javascript" src="http://www.google.com/jsapi"></script>
 3 
 4 <script type="text/javascript">
 5     if (typeof google == 'undefined') {
 6         document.write(unescape('%3Cscript src="/localmedia/jquery-1.4.min.js" type="text/javascript"%3E%3C/script%3E'));
 7         document.write(unescape('%3Cscript src="/localmedia/jquery-ui-1.7.2.custom.min.js" type="text/javascript"%3E%3C/script%3E'));
 8         document.write(unescape('%3Clink type="text/css" href="/localmedia/smoothness/jquery-ui-1.7.2.custom.css" /%3E'));
 9     } else {
10         google.load("jquery", "1.4.0");
11         google.load("jqueryui", "1.7.2");
12     }
13 </script>

延伸閱讀： Using CDN Hosted jQuery with a Local Fall-back Copy

如何處理「合併(merge)錯誤的 hg 儲存庫」? 就是再用「merge」來復原!

學弟把我們已經作好的分枝要合併進主線時，不知怎麼搞地 merge 得非常混亂，而且也 push -f 進 hg 伺服器。

我們總共有三種分枝： 'default', 'Release for XXX', 'convert to InnoDB'，這次是要把 'convert to InnoDB' 的成果合併進 'default' ，再合併到 'Release for XXX' 。'convert to InnoDB' 是我們將 django-based 的系統從 MyISAM 引擎改到 InnoDB 所作的程式碼修改。主要的修改是發生在索引上，因為原本有一個地方設定了 unique_together = (('name', 'uplevel_id'), ) ，而它會造成 MySQL Error code 1071錯誤('Specified key was too long; max key length is 767 bytes')，因為 name 的原長度是 256 ，而我們又使用 utf8 ，所以它的實際長度為 256 * 3 = 768 ，但在 InnoDB 的索引中，限制為 767 以下，所以我們必須將 name 的長度限制為 255 。

當我改完程式碼後，就請學弟們在自己的本機上測試，如果沒問題的話，就作合併的動作，並送到實際運作的網站去。

結果，他合出了下面這個東西：



D 版是我的分枝成果，我希望他把 D 合併到 B 跟 C 中。但他生出了 E, F, G, H 。這 4 個版本都不是我想要的。

一開始，我的作法是再次作手動合併，結果我迷失在那些修改的程式碼中，花了快 3 個小時，依舊無法解開，所以我當時用下策來處理，就是以 hg strip 指令把 hg 伺服器上的 E ~ H 的版本洗掉。然後重作合併。

這個方法十分爛，但當下，剛好沒有人上傳程式碼，而我又陷在那堆程式碼中，所以我選了這個作法。

這種作法，會有一個大問題，如果有人在未刪除版本前，就作了 pull, update ，那麼下次他在 push 時，就會出現衝突。他一定會 merge 到亂掉，因為他手上的 E ~ H 版本的程式碼不具含意，所以他也無法以程式碼內含意義來作合併，這樣他會像我一樣陷入毛線當中。

所以，在我解決 hg 伺服器上的亂象後，我靜下心來仔細思考，才發現我何必管 E ~ H 作了什麼事呢! 我只要在 merge 時，忽略它們的修改就行啦!

首先，我 clone 一個 LOCAL 儲存庫，而且只 clone A, B, C, D 之前的版本。作法必須分兩次，因為 clone 只會把該版本的媽媽下載下來，所以像是 A, B, C, D 4 個版本，卻有 2 個 heads ，我就得分兩個指令來下載，指令如下：

$ hg clone https://SERVER/my_software LOCAL -r C
$ cd LOCAL
$ hg pull -u -r D

然後，依我原本想要的合併方式處理：

$ hg ci -m '"convert to InnoDB" branch ...' --close-branch #P.S. 這個作法事後會造成問題 *1
$ hg merge -r B
$ hg ci -m WRITE_f'_COMMIT_MESAGE # 產生 f'
$ hg merge -r C
$ hg ci -m WRITE_g'_COMMIT_MESAGE # 產生 g'

這樣 LOCAL 的版本圖就像下圖一樣。



再來，我把伺服器上的錯誤版本 clone 到本機的 SERVER-FIX ，然後在 SERVER-FIX 中依 branch 作合併，最後合併出 'convert to InnoDB' 及 'Release for XXX' 兩種 heads ，指令如下：

$ hg clone https://SERVER/my_software SERVER-FIX
$ cd SERVER-FIX
$ hg update -C H
$ hg merge -r E
$ hg ci -m WHATEVER_MESSAGE

成果如下圖：



接下來，我回到 LOCAL 儲存庫中，把 changeset push 到 SERVER-FIX 中，成果如下圖：



最後，我要作的就是把 I, G, g' 三者合而為一，而且要在 merge 時，完全忽略 I, G 的程式碼修改，怎麼作呢? 指令如下：

$ cd SERVER-FIX
$ hg update -C g'
$ hg merge -r I
$ hg status
M models.py
$ hg cat -r g' models.py > models.py # I 版的修改，只在 models.py 上，而我又用 g' 版的 models.py 把 I 版修改完全洗掉了
$ hg ci -m MERGE_g'_I_MESSAGE
$ hg merge -r G
$ hg status
M models.py
$ hg cat -r g' models.py > models.py # G 版的修改，只在 models.py 上，而我又用 g' 版的 models.py 把 G 版修改完全洗掉了
$ hg ci -m MERGE_g'_I_G_MESSAGE

最後成果如下圖：



再為各位整理一下，合併「錯誤的 hg 儲存庫」步驟：

1. 在本機上，重作一個完全正確的 LOCAl 儲存庫。
2. 在本機上，重現一個與伺服器相同的 SERVER-FIX 儲存庫，並依 branch 作合併，讓一個 branch 只有一個 head 。
3. 將 LOCAL 的成果 push 到 SERVER-FIX 中。
4. 讓 SERVER-FIX 中的 head 與 LOCAL 的 tip 合併。而且在合併時，完全消除程式碼的修改，讓它們合併完，程式碼是與 LOCAL 的 tip 程式碼完全相同。
5. 確認無誤，就能 push 到 hg 伺服器了。

以這種方式處理完的 hg 伺服器，才可以讓所有人都免去再次合併 E~H 這段錯誤程式碼的痛苦。

基本上， hg 的主要運作方法，就是要讓所有人習慣在自己的本機上， merge 自己與其他人的成果，如果你能順暢地走完 1 ~ 4 的步驟，也代表你足以應用 hg 在大部份的程式碼修改工作了。

註1 我太早在 'convert to InnoDB' 分枝上下 --close-branch ，所以我後來在使用 hg update -C 'convert to InnoDB' 時，它居然是 update 到 I 版，而不是 e' 版。

在 django-based 系統中，將MyISAM 轉換成 InnoDB

詳細請見官方文件。

我簡單整理如下：

一、將 settings.py 中的資料庫引擎從 MyISAM(預設值) 換成 InnoDB , 加下以下設定，

DATABASES = {
    'default': {
        'NAME': 'xxx',
        'USER': 'xxx',
        'PASSWORD': 'xxx',
        'ENGINE': 'mysql',
        'OPTIONS': {
            "init_command": "SET storage_engine=INNODB",
        },
    }
}

二、將原來的表格作

mysql> ALTER TABLE ????? ENGINE=INNODB;

至於第二種方法該如何處理，我是使用 mysql 指令手動處理：

mysql> \T /home/hoamon/alter.sql;
mysql> show tables;
mysql> \q;
sh# perl -i -pe 's/| +([^ ]+) +|/ALTER TABLE \1 ENGINE=INNODB;/g' /home/hoamon/alter.sql
sh# mysql -u xxx -pxxx xxx < /home/hoamn/alter.sql

我在將 MyISAM => InnoDB 時，遇到一個問題 MySQL Error code 1071錯誤('Specified key was too long; max key length is 767 bytes')。

因為原本的 models.py 有一個 Model 設定了 unique_together = (('name', 'uplevel_id'), ) ，而它會造成 1071 Error code，因為 name 的原長度是 256 ，而我們又使用 utf8 ，所以它的實際長度為 256 * 3 = 768 ，但在 InnoDB 的索引中，限制為 767 以下，所以我們必須將 name 的長度限制改為 255 才行。