我运行了一个包含多个独立应用程序的相当复杂的项目。然而，这些使用了几个共享组件。所以我有一个类似于下面的源代码树。
所有应用程序都有自己的MSBuild脚本，用于构建项目及其所需的所有共享资源。我还在CruiseControl控制的持续集成构建服务器上运行这些构建。
部署应用程序时，它们部署在多个服务器上以分配负载。这意味着跟踪每个不同服务器上部署的构建/修订是非常重要的（我们需要在DLL版本中使用当前版本，例如“1.0.0.68”） 。
同样重要的是能够重新创建一个版本/构建版本，如果某些内容无法正常工作（o是的，发生了......），那么这些修订版本可以回滚。今天我们正在使用SourceSafe进行源代码控制，但是如果我们能够提供很好的理由（SS它实际上对我们来说工作正常，那么远）可能会改变。
我们尝试遵循的另一个原则是它只是由我们进一步部署的集成服务器构建和测试的代码。
我们有几个想法来解决上述问题。第一个是持续集成服务器构建和本地部署项目并测试它（它现在就这样做）。您可能知道CruiseControl中的成功构建会生成构建标签，我想我们可以使用它来设置可执行文件的DLL版本（因此构建标签35会创建像“1.0.0.35”这样的DLL）？我们的想法也是使用此构建标签来标记完整源代码树。然后我们可能会通过该标签检出并稍后重新创建构建。
标记完整树的原因不仅包括实际应用程序代码（位于源树中的一个位置），还包括所有共享项（位于树中不同位置）。因此，成功构建“应用程序A”将标记为整个树，例如标签为“ApplicationA35”。
尝试重新构建此版本并在部署之前设置DLL版本时可能会出现问题，因为我们无法再访问CruiseControl生成的构建标签。如果所有CrusieControl构建标签对于所有项目都是唯一的，那么我们只能使用标签号，但事实并非如此（应用程序A和B可以同时在构建35上），因此我们必须在标签。因此SourceSafe标签“Application35”。 我们如何在构建build 35后重新创建build 34并将1.0.0.34设置为DLL版本号？
有人告诉我，例如Subversion会在每次检查时为整个源树创建一个修订号 - 就是这种情况吗？ SourceSafe有类似之处吗？如果这是正确的，那么在获取最新版本并在CruiseControl服务器上构建时，想法就是获取该版本号。然后可以使用修订号来设置DLL版本号（例如“1.0.0.5678”）。我想我们可以根据需要获得Subversion的这个特定修订版，然后包含该应用程序和所有共享项，以便能够重新创建过去的特定版本。 是否可以使用SourceSafe实现这一点？
所以两个主要要求是：
那你怎么解决这个问题呢？你会选择哪种方法，如何你会解决它（或者你有一个完全不同的想法？）？ **很高兴给出详细的答案。 **
奖金问题修订号和内部版本号有什么区别？什么时候真的需要它们？
答案 0 :(得分：8)
您的方案在VSS中是合理且可实现的（尽管我建议您考虑替代方案，VSS实际上是一种过时的产品）。
对于“CI”构建 - 您将进行版本控制，查看具有“版本”任务的MSBuild Community Tasks Project。通常，您的源代码树中将有一个“Version.txt”，而MSBuild任务将增加“Release”数字，而开发人员控制Major.Minor.Release.Revision数字（这就是我的客户想要它的方式）。如果您愿意，可以使用修订版。
然后您将有一个“FileUpdate”任务来编辑具有该版本的AssemblyInfo.cs文件，并且您的EXE和“DLL”将具有所需的版本。
最后，VSSLabel任务会正确标记所有文件。
对于“Rebuild”构建 - 您将修改“Get”以从该Label获取文件，显然不执行“Version”任务（因为您正在选择要构建的版本），然后FileUpdate任务将使用该版本号。
奖金问题：
这些都是“你想如何使用它们” - 我会使用构建号，以及构建号，这就是我增加的内容。如果您使用CI，那么您将拥有非常多的构建 - 绝大多数构建无意在任何地方部署。
主要和次要是不言而喻的 - 但修订我总是用于“修补程序”指示器。我打算发布一个“1.3”版本 - 实际上它是1.3.1234.0版本的产品。在1.4上工作时 - 我发现了一个错误 - 需要一个热修复程序，如1.3.2400.1。然后当1.4准备就绪时 - 可以说是1.4.3500.0
答案 1 :(得分：3)
我需要更多空间而不是回应，因为评论直接允许......
谢谢！好答案！会是什么 差异，什么会更好 使用SubVersion解决此问题 例子？Richard Hallgren（15个小时 前）
VSS的问题与这个例子无关（虽然我认为“标签”功能实现效率低下......）
以下是VSS的一些问题
1）分支基本上是不可能的 2）通常不使用共享结账（我知道有几个人成功结账） 3）表现非常差 - 它非常“健谈” 4）除非你有一个非常小的存储库 - 它是完全不可靠的，对于大多数商店来说它是一个滴答作响的定时炸弹。
对于4 - 问题是VSS是由整个存储库实现的，在文件系统中表示为“平面文件”。当存储库超过一定的大小（我相信4GB但我对这个数字没有信心）时，你就有机会“腐败”。随着规模的增加，腐败的可能性会增加，直到几乎可以肯定。
因此，请查看您的存储库大小 - 如果您正在进入千兆字节 - 我强烈建议您开始计划更换VSS。
无论如何 - 谷歌的“VSS糟透了”给出了30K的点击率...我想如果你确实开始使用替代品 - 你会发现它非常值得付出努力。
答案 2 :(得分：3)
结果是cc.net发布版本中的所有程序集都具有相同的版本号，这些版本号符合源代码库中的标签
答案 3 :(得分：0)
UppercuT可以通过自定义打包任务完成所有这些操作，以分割应用程序。要获取源代码的版本号，您可能会考虑Subversion。
这也非常容易上手。
http://code.google.com/p/uppercut/
这里有一些很好的解释：UppercuT