May 31, 2013

[git] git branching model

前情提要是這篇 A successful Git branching model

使用這個方法,理論上正式釋出的版本都會在 master branch 裡面然後加上 tag。但在使用者不願意/不能夠做大版本升級,只能上小 patch 的情況下,如果釋出後的版本要繼續維護,就有機會遇到下面的問題。

假設 master branch 上有 1.0、1.1、1.2 這幾個版本。某一天發現有個 bug 在 1.1 這個版本開始就存在,所以需要回頭去更新 1.1 跟 1.2 把問題修掉然後釋出新版。可能的作法就是從這幾版 branch 出去,把 patch 放上去以後下新 tag 成為 1.1.1,1.2.1 這樣。

只是這樣做以後,就不是所有正式釋出的版本都存在 master,經常性存在的 branch 也不會只有 master 跟 develop,還會有這些有小 patch 的 branch。

既然很有可能要有這些 branch,最後選擇的解法就是只要釋出大版本就開 branch 出去,像是 release-1.1、release-1.2,要 patch 某個版本就直接到相對應 branch 去修改。

我自己的感覺是原本 git flow 的作法是把 release 這件事視為線性的,當現實狀況不是線性而是有分支而且分支還會成長的時候就不適用了,除了這點以外,文章其他部份還是很值得參考的。

May 02, 2013

Mongo Query

from Optimizing MongoDB Compound Indexes  

  •  For indexed queries
    • nscanned: the number of index keys in the range that Mongo scanned
    • nscannedObjects: the number of documents it looked at to get the final result
    • n: matched documents
  • "optimal index" for a query
    • include all the query's filtered fields and sort fields
    • any range-filtered or sort fields in the query must come after equality fields
    • if there are multiple optimal indexes, Mongo chooses one arbitrarily