版本控制和AssemblyInfo文件的更新

Question

我使用subversion维护（主要）C＃代码的应用程序。我想知道更新AssemblyInfo.cs文件的时间和位置的最佳实践是什么，以反映产品发布时的版本号。

让我们说我有一个主干，以及以前版本的一些维护分支和标签，以便在发生时标记每个版本。

如果我在标记之前更新分支或主干中的AssemblyInfo文件（这是我当前的方法），这意味着我可以查看该分支的日志以查看发布的时间，这非常有用，但它给了我假合并分支时合并冲突。比如说我在版本4分支中修复了一个bug，它将版本4.7更新到4.8;当我尝试将该修复程序合并到版本5分支时，AssemblyInfo必然会发生冲突。

我还考虑过更新标签本身的AssemblyInfo文件。这可以避免合并冲突问题，但意味着在查看主干或维护分支的历史记录时，您无法看到这些版本，并且它似乎也违反了标记应该是只读的原则。

从我收集的内容来看，有些人喜欢在构建过程中即时更新AssemblyInfo文件，而不是将它们存储在SVN中。虽然从表面上看，自动化版本编号似乎是一个好主意，但如果在执行构建之前立即签入AssemblyInfo文件，我认为我感觉更舒服，这样就可以直接进行编译。程序集上的版本号与其来源之间的关联。

Answer 1

只是分享经验：我是以自动方式在构建服务器 上执行此操作。我已经配置了一次而不再触摸它，除了不经常增加主要和次要版本。这是一个大纲：

• AssemblyInfo.cs已提交源代码管理
• 开发人员不会手动更改AssemblyInfo.cs
• 构建服务器获取对源代码管理的任何更改的来源
• 构建服务器自动更改AssemblyInfo
• 构建服务器生成具有正确版本的文物
• 当我标记/分支时，我使用Build Server
中的构建版本创建一个标记

现代构建服务器将具有自动更改此文件的整个过程的功能，例如，请参阅AssemblyInfo patcher in TeamCity

我使用的版本策略是：

major.minor.build_number.svn_revision_number

其中major和minor在构建服务器上手动硬编码为配置参数。 build_number由构建服务器自动递增。从{svn提交号码中获取svn_revision_number。