“最佳”；“工作惯例”；在发布版本时使用svn

我正在与svn在我的工作中实施更好的“工作实践”。几年前我们就已经使用了svn，但我认为我们只使用了它容量的20%；我们将其用于源代码版本控制，但不使用标记或分支概念

对于未来，我们希望能够在每次修订或发布后借助标签保留应用程序代码的快照。但留给我更多的问题

这是我想遵循的模式：

• 这个团队不断地在后备箱上工作
• 在每一次修订和发布时都会对主干进行标记，以便获得任何版本的快照
• 标记完成后，团队继续对行李箱进行操作
• 如果团队想要尝试什么，他们会将代码分支，并在完成后将更改合并回主干

问题是，我们还有一个应用程序依赖的自制框架。在我们的上下文中，标签的帮助是能够纠正现有版本中的一个小错误，而无需将最新版本发送给客户端；后备箱中的版本。正如您所想象的，框架与应用程序不在同一组文件夹中，因此，我认为必须创建与应用程序发布相关联的框架代码标记是非常令人伤心的。考虑到框架本身也可以在没有应用程序特定要求的情况下改变。 出于这个原因，我不知道哪种策略是创建标记的最佳策略，如果在应用程序的早期版本中发现框架中的错误，那么可以减少痛苦。目前，应用程序指的是框架，框架库位于每个应用程序解决方案的libs文件夹中。在这种情况下你会怎么做？哦，我必须指出这个框架有40万行代码。复制和过去的解决方案将被拒绝。：）

如果我必须修复以前版本中的错误，我如何处理标记？我知道每当我想签入标记结构时，Subversion都会通知我。我必须创建一个带有标签的分支，纠正错误，然后合并/签入修改返回到标签文件夹，即使Subversion通知我

我的应用程序中也有依赖项，比如，Visual Studio中也有依赖项，因为这些应用程序集成在IDE中。如果我必须纠正使用这些IDE插件的早期版本中的错误，我如何处理这种情况

最后，如果您能寄给我一些书籍或文章，帮助我对所有这些问题进行更深入的解释，我将不胜感激

---

非常感谢您抽出时间。

好吧，框架是一个软件产品，框架的客户端是使用它的应用程序。因此，框架应该遵循与应用程序本身相同的规则

下面是一个场景。您发布了应用程序的A3.0版本。此版本使用框架的F2.4版本。框架的SVN存储库有一个F2.4版本的标签。SVN存储库有一个A3.0版本的标签

应用程序的客户端在A3.0版本中发现一个bug。您将创建一个名为A3.0.1的新分支，用于修复该错误。framewok与此bug无关。因此，您在这个分支中修复了应用程序的代码，将修复程序合并到它适用的主干上，准备好后，发布并创建一个名为A3.0.1的标记。在分支和标记中，您仍然在使用框架的F2.4版本

客户端在A3.0.1中发现另一个bug。因此，您创建了一个名为A3.0.2的新分支来修复此错误。经过调查，您意识到这是针对框架的。因此，您要求框架团队修复此缺陷，并为您提供F2.4.1版本。在框架团队中，他们创建了一个分支F2.4.1来修复bug。一旦准备就绪，他们将发布F2.4.1并为此版本创建一个标记。在分支A3.0.2中包含F2.4.1，确保bug已修复（可能还需要对应用程序代码进行一些更改），准备就绪后，发布版本A3.0.2并为其创建标记。您的版本A3.0.2现在依赖于框架F2.4.1

关于VS插件，如果它们不向后兼容，除了保留旧版本，我看不到任何其他解决方案。但我不会依赖IDE，更不用说IDE的特定插件来创建和构建软件。IDE应该是可互换的，并且至少应该有一种独立于IDE的方式来构建软件