4

我们已经开始在工作中使用功能分支模式。

一切似乎都运行良好，这是我们使用的步骤：

  1. 开发者分支主干
  2. 开发人员使用分支完成实施和测试
  3. 开发人员将主干合并到分支中，使分支保持最新状态以备重新集成
  4. 维护者将分支重新集成到主干中
  5. 版本、构建和标记。

开发人员拥有对分支文件夹的读/写权限，对标签和主干的读权限

维护者对所有文件夹具有读/写权限

我们使用 svn 1.5.1（在服务器上仅限于 Ubuntu Server 8.04），尽管我们正在迁移到具有最新 svn 的最新服务器（Ubuntu Server 12.04）。

我们的客户端 TortoiseSVN 1.7.6，svn 客户端版本 1.7.4。

到目前为止，一切都运行良好，我们有多个开发人员同时编写功能。

然而，目前我是唯一被提名的维护者，一旦流程敲定并且人们已经接受了足够的培训，其他人将被提名。

我担心的是，一个过程变得更加自主，我的直接参与减少了，可能会发生以下情况，我不知道如何防止它们：

  1. 开发人员忘记了一个分支已被重新集成并意外地向它提交了工作
  2. 维护者没有充分检查分支是否是最新的并准备好重新集成并执行重新集成和提交。

我在 Tortoise 或 SVN 中看不到任何警告或阻止你这样做的东西。

再说一次，我并没有试图做出任何令人讨厌的事情，只是为了看看它做了什么。

如何自动防止用户做出这些错误的提交？

4

3 回答 3

2

我看不到分支的多次重新集成（对于 1.7.X SVN）有什么不好 - --reintegate 不会将分支转换为非功能子树，下一次合并只是提交分支中的更改

而且，顺便说一句，merge --reintegrate如果主干未与分支范围同步，则会失败。

作为最后的手段，功能分支的 ACL 可以在重新集成到每个人的 RO 或从存储库中删除的分支后受到限制

于 2013-05-28T14:59:45.493 回答
2

看起来你会喜欢Subversion 1.8 中的自动合并。

检查 SVNBook 章节“重新集成分支”。如本章所述，您可以在完成后删除重新集成的分支。

然而：

如果在将分支重新集成到主干后选择不删除分支，则可以继续从主干执行同步合并，然后再次重新集成分支。如果这样做，则只有在第一次重新集成后对分支所做的更改才会合并到主干。

于 2013-05-28T12:46:43.317 回答
2

我们有一些类似的问题，并以一种组织方式解决它：当一个分支最终合并到主干时，它将在团队会议中进行沟通，然后分支将被重命名，所以这样所有现有的结帐都“死”了——意外签到是不可能的。效果很好（在我们的团队中）。

于 2013-05-28T12:50:09.150 回答