2009-04-30 60 views
10

我正在開發一些分佈式團隊的類庫。我們使用Subversion進行源代碼管理。一個開發商希望提交自己OBJ目錄庫,這從來都不是標準的做法對我來說。最佳做法是什麼?優缺點都有什麼?我應該將編譯的二進制文件添加到我的Subversion存儲庫嗎?

+2

他爲什麼要提交他的bin和obj目錄?他有充分的理由嗎? – Grant 2009-04-30 12:35:41

+0

參見http://stackoverflow.com/questions/709372/alternative-to-binaries-in-subversion – 2009-05-01 01:20:50

回答

6

你當然不應該將任何編譯的文件添加到主分支。你無法將它們與通常的工具進行比較,它們會減慢一切。

在發佈的版本分支,您可以包括他們有原編譯的文件,是因爲編譯器改變或者這樣的事情不會有差別。但是你很可能將所有的二進制版本存儲在別的地方,Subversion並不是真正的地方。

2

我們也排除這些文件,因爲它們的方式隨着時間的推移「污染」您的修改。因此,在每次提交中,您都會更改其他一些文件,但您只會對已更改的源代碼感興趣,而不會對已編譯的文件感興趣。

所以,想象一下你正在試圖檢查什麼地方出了問題XYZ修訂,您在變化以下看看...

A.DLL

B.DLL

c.dll

d.cs

e.dll

... ... ...

,但你只可能在源感興趣,所以版本比其他污染這些文件並沒有多大意義,也因爲你不能因爲什麼二進制文件內改變反正..

3

我們沒有提交bin和obj文件,因爲它們是在編譯時創建的,所以沒有真正的需要。不知道這是否是最佳做法,更多是個人意見。

我想你可以有「已完成的dll」或東西單獨的文件夾,如果它是一個DLL的漢化版?

4

我能看到爲什麼你可能要提交的垃圾箱,例如,如果你有不同的版本,則需要維護需要的DLL的特定版本的應用程序。但即使在這種情況下,您也可以始終在標籤/分支上創建新的分檔。

至於犯OBJ文件,我想不出任何比較好的理由這樣做..

17

我的規則是,所有生成的文件除外。

+0

對我來說也是一樣,只有web項目的一個例外。由於一些DLL可能不是你的代碼,並且該站點不會直接從源代碼中運行。 Web項目沒有引用機制將項目設置爲新鮮是在尋找依賴關係中的屁股疼痛。 – 2009-04-30 13:14:30

4

我不會將編譯的庫文件添加到源代碼管理,除非您沒有源代碼。

例如:

第三方庫/對此我沒有源=下某種「相關性」文件夾的源代碼控制去控制。

我們寫=只有源的所有庫是在倉庫中,從來沒有二進制文件。

2

除非有一個你沒有提到的好理由,否則不要將你的bin目錄添加到源代碼管理中。我看不到任何好的理由來提交你的obj目錄。

4

通常我從不將bin目錄綁定到源代碼管理系統。原因是它必須是自動重現的,所以沒有必要將生成的dll添加到源代碼管理。

生成的源文件也是一樣,但有一個例外:如果需要時間或者必須有基礎結構來生成源文件,那麼我將它們添加到源代碼管理中。

當你想管理不同的版本時,分支方法將是我最喜歡的。

1

我儘量不在源碼控制系統中存儲任何二進制文件 - 甚至沒有我們沒有源文件的庫。讓存儲庫中的二進制文件擴大存儲庫並使檢出緩慢。

我們使用Maven來構建我們的Subversion項目。在maven中,應用程序所需的所有二進制文件(但不是由您的應用程序創建)都存儲在Subversion之外的所謂Maven存儲庫中。 Maven使用約定將「版本」附加到應用程序使用的二進制文件中。這些文件很容易被應用程序和開發人員共享(每個人一份)。

0

我已經看到有價值的唯一情況是在一個n層應用程序中,一些二進制文件從一層分發到另一層。

例如,部分代碼表示所有層使用的公共對象。然後,每一層實際上都是它自己的子項目,它使用引用爲二進制文件的公共對象,但僅在該層上工作就依賴於二進制文件。在這種情況下,即使在整個項目中都有源代碼,實際上二進制文件是項目的一部分,就像第三方庫一樣。

在這種情況下,通過在源代碼控制中凍結正確版本的二進制文件而不是始終從源代碼構建,確保該層繼續成功編譯可能是有意義的。這就是說,如果你可以使這種範式無效,並且在每一層的構建中包含所有的依賴關係,生活將變得更加容易。把源項目的一部分放在另一部分的二進制文件中並不美觀,並且可能導致災難。

0

我們不提交bin或obj文件夾,我們用來在庫的根目錄下創建一個名爲library的新文件夾,並且在那裏放置所有重要的dll文件,例如使用的第三方工具,例如ajaxtoolkit,fckeditor ,....和其他的dll文件,我們認爲它對這個項目很重要。

0

那麼,讓我們玩魔鬼的擁護者......這裏是將DLL存儲在存儲庫中的一個例子。

公司A在任何給定的時間點都有6支團隊。這些團隊中的大多數至少使用C#開發其部分產品。考慮到公司A的特定性質,標準的DateTime類沒有足夠的功能,因此他們已經開發了他們自己的從DateTime派生出來的類,它們在DLL中可用。

6個組中的每個組在存儲庫中都有其自己的目錄,並且大多數都需要DateTime DLL,因此它們在每個產品目錄中都有一個已編譯DLL的副本,並且只有在有新的時候纔將新副本推送到目錄可用的功能,該目錄中的項目需要。

是否有另一種解決方案可以帶來以下好處?: 1)防止開發人員檢查兩個目錄在單個項目上工作。 (在現實生活中,有兩個以上,但爲了這個例子,我們稱之爲兩個)。 2)當只有一個產品需要更改DateTime類時,防止QA不得不重新測試所有產品。

相關問題