SVN标记文件生成就绪

Question

我是SVN的新手，我没有详细使用它，基本上只是检查中继并提交然后导出和部署。

我正在与一些开发人员合作开展一个大项目，我们正在寻找最佳的部署流程。我们所关注的一件事是标记，分支等的最佳方式。我们习惯于CVS，您需要做的就是提交一个文件并将其标记为生产就绪，否则代码将无法部署。

我看到SVN处理标记与CVS不同。我想我正在看这个并使它过于复杂。似乎在没有生成代码的情况下处理项目和提交文件的唯一方法是在分支中执行它，然后在准备好部署它们时合并这些更改。我假设您也可能正在处理应该部署的其他代码，因此您必须在工作副本之间切换，否则您正在处理一个没有与主干或生产分支混合的分支？

这个过程似乎过于复杂，我想知道是否有人能给我你认为最好的管理方法。

Answer 1

我们做了以下事情并对此非常满意：

• 小功能和错误修正（花费不到两天）是在主干上进行的。树干应该始终足够稳定，以便在不到一周的时间内“释放”。
• 更复杂的功能和错误修正在功能分支上实现，稍后重新集成到主干中。
• 每个构建（我们有一个构建服务器）都会获得一个包含其版本号的标记。
• 一旦我们接近发布，就会从最新的一个标签创建一个发布（或错误修复）分支。这样，下一个版本的新功能已经可以在主干上提交，但只有当前版本的功能（和错误修正）才会合并到发布分支。

我有一个项目文件夹，我检查了主干，最后几个发布分支和我正在处理的功能分支。这样我就可以轻松地在不同分支之间进行提交和合并。

另外两个有用的规则：

• 在主干上创建错误修正并将它们合并到发布分支，而不是相反。否则你可能会忘记将错误修正合并到主干，这将使下一版本中已经修复的错误再次出现。
• 每周将主干上的所有更改合并到您的功能分支，以防止两个分支漂移太远。如果您在尝试重新集成功能分支之前需要数周或数月才能通过，则可能需要花费数天或数周才能解决所有冲突。如果您每周从主干到功能分支合并，则不会发生这种情况。

Answer 2

使用SVN（以及大多数其他集中式VCS）有两种思路：

1. 稳定的中继线 - 中继线是所有稳定良好的代码所在的位置。只对主干进行安全的“单个工作单元”更改。您的所有开发都在分支中完成，然后合并到主干。当它是释放时间时，你从行李箱中标记。

2. 不稳定的树干 - 树干是你的“前沿”。所有新东西都被提交到主干。当你的作品开始凝固成一个版本时，你会做一个分支，你可以在那里稳定和抛光一切。你最终会得到每个版本的分支（branches / v1.0，branches / v1.1等）。您准备好时从发布分支进行标记。

关于模型＃1的注释：

• 人们可以在分支机构工作而不会互相踩踏。
• 您可以根据需要划分不稳定的开发工作，甚至是每个开发人员一个分支。
• 您可以拥有分层分支，它们之间具有质量门。示例：Joe将不稳定的东西提交给他的私有分支，当Joe对他的工作感到满意时，它会合并到团队级分支，然后进行更正式的测试，然后通过完全测试的工作将其合并到主干中。其他球队。
• 这意味着在两个方向上都有很多合并。东西被推到后备箱。中继线更改需要传播到分支机构。
• 在SVN的合并跟踪功能之前，这真的很难。

关于模型＃2的注释：

• 开发工作更具协作性。它阻止人们孤立地工作太久，然后将bomb放到代码库上。
• 除非你通过预提交测试强制执行某些规则，否则会有很多破坏的构建。
• 它鼓励保持代码库的模块化，因此您不必让所有人同时在主干中更改相同的文件。
• 此模型可以更轻松地管理旧版本和新版本的更新（例如，您正在发布v1.x和v2.x的错误修正）。
• 对于长时间运行的更改，您可能还需要一个分支来处理该功能。

我看到两种模型都运行良好。这取决于团队的工作方式以及代码库的结构。

Answer 3

  

处理项目并在没有生成代码的情况下提交文件的唯一方法是在分支中执行此操作，然后在准备好部署它们时合并这些更改。

绝对正确。这是与SVN，TFS和大多数现代源控制管理系统一起使用的方法。

正常的工作流程是拥有一个尽可能接近生产的TRUNK分支，以及完成工作的Main分支 - 对于大型功能，您可以从Main分支创建子分支。

有分布式SCM，例如Git和Mercurial不能以这种方式工作，但你很可能会发现它们比SVN更复杂。

请参阅this关于一个分支策略的博客文章（有效的SVN分支策略）。

Here是另一个（简单分支并与SVN合并）。

Answer 4

最佳流程取决于多种因素。你的变化有多大，它们是什么类型（错误修复，新功能），你有多少开发人员？

一般情况下，我建议使用分支来处理可能影响整个软件的大型新功能或大型重构。可能会在主干上开发小错误修正或不影响其他部分的小功能。

但是你似乎有的主要不安可能通过实际使用两个中继来解决。一个用于当前的开发/测试版本，另一个用于当前的稳定版本。然后，您可以在部署之前将更改从开发合并到稳定。最后，这或多或少像所有开发人员共同的另一个分支。

幸运的是，颠覆让你可以毫无问题地完成任何任务。

获取更多信息的最佳来源可能是SVN Book