The design of trac aggregator
前陣子我在 blog 上簡單介紹了 Trac Aggregator，因為在工作上總是必須多個專案同時進行，相互依存，又因為當初規劃 repository 的決策，造成搭配 Trac 時，因為 Trac 沒有 multi-project support，而使用起來非常麻煩[1]。所以只好簡單地寫了這個 PHP script 當作個人工作用的 issue portal。
其實說穿了很簡單，Trac 的 report 是藉由讓使用者自行編輯 SQL 指令而產生的。而 Trac 的資料庫就放在 TRAC_ENV 下的 db/trac.db 這個 SQLite 資料檔裡。所以我們只要自己用 PHP 開 SQLite 資料檔，然後把 Trac 裡的 report 的 SQL 指令搬過來，排版 output 一下，簡易版 Trac Aggregator 就完成了。
比較麻煩的，反而是如何呈現跨專案的 ticket list。由於每個專案的 milestone 進度都不會相同，排序的問題就相對地複雜很多。目前我只是簡單地在 script 裡，用 compositional compare function 的方法，建立多 key 的 sorting 機制，以便我可以依需要改變排序方法。但 milestone 進度的問題，依然還是沒有解決。這是下一階段的目標。
- 因為這些專案其實都不會大到，需要在 issue tracker 裡在細分 components 各別追蹤，如果我是把所有專案都放在同一個 project 裡的話，剛好可以用一個 TRAC_ENV 管理所有專案，用 components 來區分不同的專案。不過話又說回來，這樣子 Trac 的 Roadmap 功能就又不是那麼的適用了。 ↩
2 Comments
何不將多個專案放在用一個Trac做管理，包含各個專案的Repository，例如:
http://mirror.sars.tw/SVN_book/book.html#svn-ch-5-sect-6.1
裡面 Figure 5.2 的配置方式
Citypig,
您好。在一個 repository 裡放多個 projects，然後這個 repository 對應由一個 trac 管理這些 projects，確實可以達到 multi-project 的效果。不過：
1. Trac 沒有 multi-project 的概念，所以我們必須要挪用 component 欄，加進 project 的層級，如將 component 的值設計成這樣：PrjectA:ComponentX、ProjectA:ComponentY、ProjectB:ComponentZ。不過，如果需要強制讓 ProjectA 的 tickets 只能 refer 到 ProjectA 的 URL，則必須另外撰寫 macro/plugin 處理。
2. 在實務上，我的經驗是，將不同的 projects 放在各自獨立的 repository 裡，比較不容易碰到 svn 的極限，備份與恢復也比較容易。
Jeff Hung
Post a Comment