2012-09-22 58 views
2

我一直在尋找一個簡單的方法來保持在版本控制一些待辦事項和注意事項以及我個人的項目,並在這個過程中我碰到ditz和錯誤來到處保持額外的文件(待辦事項列表,包裝)。 Ditz自述文件提到有三種不同的文件維護方式,一種是:在一個分支

將問題數據庫保留在存儲庫中,但保存在單獨的分支中。問題更改可以由您的VCS管理,但不直接綁定到代碼提交。

這讓我覺得我可以使用相同的東西來保留一些文件用於打包在一個存儲庫中與我現在分開的幾個其他開發人員共享的存儲庫中。所以我有幾個問題:

  1. 爲什麼我應該使用/不使用這種方法?
  2. 這是如何設置?不是專門針對Ditz,而是針對任何文件。
  3. 它是如何工作的一天到一天嗎​​?

我幾乎沒有分支的經驗,而且我看它的每一處都用來保留稍後將合併的主幹的編輯副本。 我主要使用顛覆,但只要它翻譯,一個dvcs的答案也沒有問題。

更新

我看起來更到這個位,這就是我發現。以下內容適用於顛覆。

從svnbook,

Subversion有一個唯一的分支副本

這可能意味着SVN分支都沒有什麼建議在ditz自述的內部沒有概念。在我看來,使用svn:externals可以達到什麼樣的效果。假設以下結構:

/trunk/project1/ 
/trunk/project2/ 
/branches/notes/ 

一個可以設置在PROJECT1和項目2到svn:externals屬性:

notes http://reposerver/branches/notes 

這種方式更新項目的工作副本也將得到「外部」的筆記,但提交將需要分別爲項目X樹中的註釋和其他文件進行。除此之外,一切都會和往常一樣。缺點是或多或少是svn:externals的缺點,即只適用於目錄並且它們被定義爲絕對URL。

不過,如果任何人有任何進一步的見解,我會感興趣。

回答

0

既然有這麼多既開源和專有跟蹤器可用,我很懷疑這是明智的使用你提出的解決方案。例如,Trac被集成(特殊提交的信息顯示提交,允許收門票(或TODO的項目,如果你喜歡)等)的源代碼控制。基於文本文件的TODO列表並不那麼靈活;你也應該考慮到你真的需要把你的任務放在正常任務跟蹤器以外的文件中。也許你沒有把重點放在基本問題上?

+0

有幾個原因,我不想要像trac或redmine的東西。主要是設置自我託管解決方案並不現實,我想盡可能避免依賴雲。同樣對於我的小型項目,其中一些僅僅是文檔,可能是一種矯枉過正或不匹配,因爲我不只是想以這種方式存儲錯誤。你的建議絕對有效。 – user18197

相關問題