跨平臺的源代碼管理？

我們正在爲.NET（使用VS 2008）和Java（使用eclipse）進行開發。跨平臺的源代碼管理？

目前，我們使用CVS，但Visual Studio 2008並沒有真正的好插件，所以我我正在尋找能夠更好地支持VS 2008和Eclipse的產品。

我最初的想法是SVN，因爲它是非常接近CVS，但我有點動心使用像水銀。我在尋找使用簡單的東西，並且對這兩種平臺都有良好的插件支持。

2009-07-02 Jesse

Subversion可能不是您最糟糕的選擇，尤其是因爲將CVS Repository遷移到Subversion相對容易。雖然沒有嘗試過任何VS插件（通常用於Tortoise SVN）。 – Daff 2009-07-02 13:45:35

你確定改變版本控制系統不只是治療症狀，而不是原因？你爲什麼試圖提高簽入率？一些開發者是否每週只提交一次，導致長時間的合併會話/破解版本？ – jared 2009-07-02 14:33:01

它會治療症狀。問題在於一些開發者根本沒有檢查，除非被問及，如果合併一個月的價值變化，合併是一個皇室的痛苦。 – Jesse 2009-07-02 14:58:32

我可以告訴你，真的有Subversion版本的Eclipse和Visual Studio 2008（AnkhSVN爲Visual Studio）不錯的插件。如果您打算將它與最新的Subversion版本一起使用，您必須確保下載AnkhSVN的每日版本。此外，還有一些工具（http://cvs2svn.tigris.org/）可將數據從CSV遷移到SVN。

對於水銀奧德Git的 - 我沒有得到與任何經驗。

我認爲SVN將給你流暢的transision - 但它不會給你的「大變革」（如果這是你所追求的）

來源

2009-07-02 13:47:08 bernhardrusch

我同意。如果你不想過度搖擺船，SVN絕對是最好的選擇。我非常喜歡GIT，但它確實需要不同的思維方式。 – GreenKiwi 2009-07-02 23:10:58

我們同時使用VSS（現在顛覆）兩個J2EE和.NET在不同的項目上。兩者似乎都可以工作。

你爲什麼就這麼掛了IDE pulgins？就我個人而言，我可以帶走或離開......我把它們放在「沒有增加任何實際價值的小工具」中。

乾杯。基思。

來源

2009-07-02 13:47:43 corlettk

有AnkhSVN和VisualSVN之間的爭論，如果你決定去與SVN。

就我個人而言，我喜歡安赫。它對我來說是免費的，更直觀的，併爲我的項目狀態提供更多有用的反饋。不過，我有一些腐敗問題，但沒有花費我幾分鐘的時間。

來源

2009-07-02 13:47:44 JoshJordan

VisualSVN客戶爲Visual Studio的
SubClipse爲Eclipse
VisualSVN Server服務器

來源

2009-07-02 13:55:44 Rad

我用Vault從SourceGear。它使用起來很簡單，並且與Visual Studio和Eclipse有很好的IDE集成。它也使用Mono在Linux上進行了全面測試。

它是免費使用單個用戶，所以你可以嘗試之前，你買。

檢查一下，看看你的想法。 http://www.sourcegear.com/vault/

來源

2009-07-02 13:55:56

在Eclipse和Visual Studio中使用svn後，我發現eclipse插件（特別是subversive）通常更加無縫地集成到IDE中。 Ankh和VisualSVN都做得很好，但是在使用.net時我更傾向於使用ToirtoiseSVN。在Eclipse中我幾乎不會訴諸ToirtoiseSVN。

說實話，我認爲IDE插件不應該推動你的決定太多。

來源

2009-07-02 13:58:51 serg10

嘗試Plastic SCM在Linux，Mac和Windows上工作。基於GUI的複製，分支瀏覽器，高效的分支和合並（包括合併跟蹤，移動和重命名），基於ACL的安全性... ...

來源

2009-07-03 00:03:51 pablo

我個人喜歡Perforce。不是免費的，但跨平臺，非常好。

來源

2009-07-03 05:52:07

我們是一個.NET，Java和Rails的店鋪

我們用顛覆多年，它的一個夢幻般的系統，做了我們認爲我們從供應鏈管理所需的一切。大約9個月前，我們開始玩Github.com，同時開發一個Rails應用程序（Rails社區中不可避免的）。

從那時起我們已經完全轉向Github.com使用私人回購爲我們的閉源商業軟件開發。

Git讓我們在幾個月內不會破壞構建或破壞代碼 - 這種情況曾經不時發生，並使我們放鬆了一天的工作，嘗試糾正問題。 Subversion不會爲您提供Git所執行的工作方法的靈活性。如果您遇到麻煩（破解版或修補程序），Subversion不會幫助您，甚至會對您產生不利影響。它的分支/合併機制很難使用，因爲它沒有跟蹤分支的起源。另外，當您合併時，您的更改歷史記錄會進行修改，以使特定分支中團隊的所有更改歸屬於執行合併的用戶。由於您所使用的整個回購都是本地化的，所以Git也閃電般快，當您在偏遠地區工作時，這一點非常明顯。

也就是說，Subversion需要一兩個星期才能熟練掌握，Git至少需要一個月的時間，尤其是如果你來自Subversion或CVS。如果你假裝它只是一個更現代化的SVN或CVS，你會因編程工作流程缺乏改進而感到沮喪，並且你會被衆多的命令所困擾。

我們有一個3分支安裝程序：修補程序< - >主程序< - >開發。在正常情況下，開發團隊將在開發部門工作。對於每個用戶故事，開發人員將創建一個關閉開發分支：開發< - >用戶故事。當故事完成時，用戶故事與開發合併，用戶故事分支可能被刪除。這種情況一直持續下去，並且在構建管理器決定將其開發中的所有變更重新合併到主數據庫中之前，主數據庫保持穩定且不受影響。如果客戶手機需要修補程序的同時，也可以與主服務器隔離開來，並且可以合併到代碼庫的其餘部分（主開發人員&開發版），以便將來在適當的時候使用。

現在用於GUI和SCM。我們避免他們像瘟疫一樣。圖形用戶界面不利於SCM的工作。我知道 - 有爭議，但請聽我說。命令行會比GUI更慢，當你在使用SCM時，你很可能會對中央回購做一些壞事或破壞性的處理，所以慢是一件好事。緩慢讓你思考你的行爲。我所見過的所有典型的GUI（EclipseSVN，TortoiseGit/SVN）都會預先選擇最近的更改作爲您即將提交的提交的一部分，無論這些更改是否已準備好提交。壞！！！！你需要考慮你的提交以及它們需要的塊狀或顆粒狀 - 命令行在這方面比圖形用戶界面做得更好。我們所有的.NET編程人員，都很喜歡通過圖形用戶界面執行任務，使用命令行Git和之前使用的命令行SVN，只是出於上述原因。這給了他們更大的控制感。

來源

2009-07-03 06:54:08 Ijonas

我不是這方面的專家，但在GUI或IDE SCM擴展中，我一直不堪重負。我一直在使用SVN，而GIT與在sourceforge上託管的項目相當不錯。我的2美分價值。乾杯！

來源

2012-12-08 19:35:10

跨平臺的源代碼管理？

回答

相關問題