VCS和單個開發人員「團隊」

Question

我是一位爲我公司開發項目的單一開發人員。我使用Subversion和Trac（用於錯誤跟蹤和與管理類型的通信）。我有一個登臺服務器和一臺生產服務器。今天我檢查了一些代碼，發現我的基於FSFS的svn（v1.4）存儲庫無可挽回地損壞。雖然這非常令人失望，但它爲我提供了將VCS /臨時系統轉移到更現代的發行版（目前是2年曆史的系統）的機會。 （就回購而言，我確實有一個沒有損壞的當前版本的代碼，所以雖然我失去了開發的所有歷史和評論，但我並沒有丟失任何代碼。）

當前我在Ubuntu上開發，生產運行RHEL5-64。我的硬件將保持不變，一個32位x86單核系統。

我對SVN和它的構造很熟悉，但我感覺FSFS腐敗問題有點燃燒。我對git的瞭解不多，只是它很受歡迎。我目前使用Trac來管理問題，我真的很喜歡它與svn的集成。似乎有插件來支持Git，但我不確定該開發的成熟度。

目前我正在考慮建立如下：

1. 的Ubuntu 8.10桌面（再加入 的Apache2和其他包...的 我最後一次嘗試添加一個GUI來 服務器版我只是 拉着我的頭髮）
2. SVN（因爲我 熟悉它和Git似乎是 了一個人 隊有點大材小用）
3. 茶c（因爲我很熟悉 ，它與SVN一起工作）。

我想對我的「新」vcs系統提出一些建議和想法。是否有我應該轉向Git的理由？有什麼比Trac「更好」？

Answer 1

Git是一個很好的源碼控制系統，特別是如果你對命令行感到滿意的話。 SVN顯然是一個很好的舊主力，現在1.5合併支持現在好多了。

Trac很好，但是當我們看到它時，它僅限於單個項目，並且在源代碼管理支持部門中不是很好。

我們現在使用redmine，它允許多個項目，並允許我們爲每個項目使用不同類型的源代碼控制，包括git。

哦，是的，我們使用哈德森建設:)

Answer 2

我對我所有的個人項目都使用git。我無法想象有什麼更好的。一旦項目超越你，它特別有用。除了偶爾推動公共回購之外，您的開發過程幾乎不需要改變。

Answer 3

SVN（因爲我熟悉它和Git似乎是一個人的團隊有點大材小用）

Git是相當重量輕，使用方便。語法與subversion稍有不同，但就是這樣。我不會說這太過分了。沒有什麼比使用subversion更復雜或者更簡單。

對於錯誤跟蹤，我使用一個名爲Pivotal的基於Web的系統。它是免費的（現在），它內置了一些項目管理功能。對於小型團隊來說非常棒，因爲它非常簡單，幾乎不需要使用設置。

Answer 4

我們在這裏使用svn/trac/ubuntu。

爲了減少腐敗的影響，我建議你實現一個自動化作業（cron？）來每天一次hotcopy svn和trac存儲庫並將它們發送到異地（rsync）進行備份。我們在這裏使用NAS，但像S3或Dreamhost這樣的產品也可以。

這樣，如果出現問題，您將只會失去一天的工作。

熱拷貝SVN：

svnadmin hotcopy $REPOSITORY $DESTINATION 

熱拷貝TRAC：

trac-admin $REPOSITORY hotcopy $DESTINATION 

Answer 5

Perforce是免費的，在啤酒長達兩個用戶，並具有good reputation。

Answer 6

我第二個爲Redmine的建議。雖然我主要是Mercurial用戶，但也支持git（和Darcs，svn和cvs一樣）。關於分佈式版本控制系統的好處之一是你基本上可以免費獲得備份（你知道你應該完成舊svn回購的備份，對嗎？）...

Answer 7

我要退後一步了採取更大的看法。如果你對SVN和Trac很熟悉和熟悉，並且他們爲你完成了工作（忽略了一秒鐘的腐敗問題），我會質疑需要移動。這是源代碼管理和錯誤跟蹤，一般而言，只要他們爲您的團隊工作，我不會看到花費大量精力來管理他們的環境，安裝和評估新工具等。

我的10,000英尺。建議將是利用這個機會來完全考慮外包這個功能。有主機（免責聲明：我的公司是一家），將免費/低成本地爲您提供Subversion，Git，Trac，Lighthouse等。然後，當磁盤陣列，FSFS或其他什麼地方出現問題時，那些花100％的時間擔心這個問題的人可以處理它，很可能沒有你意識到這個問題。如果您的公司的政策允許您使用主持人執行此功能，那麼您現在可以節省一個週末，一個週末（下一場災難）以及無數美元的生產時間。