我应该将编译的二进制文件添加到我的Subversion存储库吗？

Question

我正在开发一些分布式团队的类库。我们使用Subversion进行源代码控制。其中一个开发人员希望将 bin 和 obj 目录提交到存储库，这对我来说从来就不是标准做法。什么是最佳做法？有什么优点和缺点？

Answer 1

我的规则是排除所有生成的文件。

Answer 2

您肯定不应该将任何已编译的文件添加到主分支。你无法将它们与通常的工具进行比较，它们会减慢一切。

在版本的版本分支中，您可以将它们包含在原始编译文件中，这样就不会有差别，因为编译器已更改或类似这样的内容。但是你很可能将所有的二进制版本存储在其他地方，Subversion并不是真正适合它的地方。

Answer 3

我可以看到为什么你可能想要提交垃圾箱，例如，如果您需要维护的应用程序的不同版本需要特定版本的DLL。但即使在这种情况下，你总是可以在标签/分支上建立新的垃圾箱。

至于提交obj文件，我想不出任何有理由这样做..

Answer 4

除非您没有源代码，否则我不会将已编译的库添加到源代码控制中。

例如：

我没有源的第三方库/控件=在某种“Dependencies”文件夹下的Source Control中。

我们编写的任何库=只有源位于存储库中，而不是二进制文件。

Answer 5

通常我从不将bin目录绑定到源控制系统。原因是，它必须是可自动重现的，因此将生成的dll添加到源控件没有任何价值。

同样的事情是生成的源文件，但有一个例外：如果需要时间或者您必须有一个基础结构来生成源文件，那么我将它们添加到源控件。

当你想管理不同的版本时，分支方法将是我最喜欢的版本。

Answer 6

我们不提交bin和obj文件，因为它们是在编译时创建的，所以没有真正的需要。不知道这是一种最佳做法，更多是个人意见。

我想你可以为“已完成的dll”创建一个单独的文件夹，或者如果它是dll的完成版本的话？

Answer 7

我们也排除了这些文件，因为它们会随着时间的推移而“污染”。因此，在每次提交时，您都会更改一堆其他文件，但您只会对已更改的源代码感兴趣，而不会对编译后的文件感兴趣。

因此，想象一下，您正在尝试检查XYZ版本中出现的问题，并在更改中看到以下内容......

A.DLL

B.DLL

c.dll

d.cs

e.dll

... ... ...

但您可能只对源代码感兴趣，因此对污染以外的其他文件进行版本控制也没有多大意义，因为您无法在二进制文件内部进行更改...

Answer 8

除非有一个你没有提及的好理由，否则不要将bin目录添加到源代码控制中。我看不出任何有理由提交你的obj目录。

Answer 9

我尽量不在我们的源代码管理系统中存储任何二进制文件 - 甚至不存在我们没有源代码的库。将二进制文件放在存储库中会使存储库膨胀并使检出速度变慢。

我们使用Maven来构建我们的Subversion项目。在maven中，应用程序所需的所有二进制文件（但不是由您的应用程序创建）都存储在Subversion之外的所谓的Maven存储库中。 Maven使用约定将“版本”附加到应用程序使用的二进制文件。这些文件很容易被应用程序和开发人员共享（每个人都有1份）。

Answer 10

我见过的唯一有价值的案例是在n层应用程序中，其中一些二进制文件从一个层分发到另一个层。

例如，部分代码表示所有层使用的公共对象。然后每个层实际上是它自己的子项目，它使用引用为二进制文件的公共对象，但仅在该层上工作仅依赖于二进制文件。在这种情况下，即使整个项目中的源代码存在，实际上二进制文件也是项目的一部分，就像第三方库一样。

在这种情况下，通过在源代码管理中冻结正确版本的二进制文件来确保层继续成功编译是有意义的，而不是始终从源代码构建。

话虽如此，如果你可以使这个范例无效，并且在每个层的构建中包含所有依赖关系，那么生活将会容易得多。将源项目的一部分的二进制文件放在源代码中的二进制文件并不漂亮，可能导致灾难。

Answer 11

我们不提交bin或obj文件夹，我们曾经在名为库的存储库根目录上创建一个新文件夹，我们将所有重要的dll文件放在那里，例如使用过的第三方工具，例如ajaxtoolkit，fckeditor， ....和其他dll文件我们认为它对这个项目很重要。

Answer 12

好吧，让我们扮演魔鬼的拥护者......这是将DLL存储在存储库中的案例。

A公司在任何指定时间点都有6个以上的团队。这些团队中的大多数至少在C＃中开发了部分产品。鉴于公司A的特定性质，标准的DateTime类没有足够的功能，因此他们开发了自己的类，这些类是从DateTime派生的，它们在DLL中可用。

6+组中的每一组在存储库中都有自己的目录，并且大多数都需要DateTime DLL，因此它们在每个产品目录中都有已编译的DLL的副本，并且只有在有新功能时才将新副本推送到目录可用，该目录中的项目需要。

是否有其他解决方案可以带来以下好处？： 1）防止开发人员检查两个目录以处理单个项目。 （在现实生活中有两个以上，但为了这个例子，我们称之为两个。） 2）当只有一个产品需要更改DateTime类时，防止QA重新测试所有产品。