我们如何在中央/共享存储库中管理粒度变更集？

Question

我在本地使用了Mercurial多年，但现在我们正在我公司做一个从Subversion切换的试点。

我们正在接受这样一个事实：开发人员现在将制作更细粒度的变更集 - 其中一些甚至可能无法构建。当开发人员将他们的更改推送到中央存储库时，所有这些更改集都将显示在历史记录中 - 这是自然的和预期的。

我的问题是：我们如何处理这样一个事实：因为更改集更精细，这使得开发人员可以更新到不构建的修订版本？我们来自一个可以在存储库中的任何地方结账的世界，并且合理地期望能够从那时开始发布。对于DVCS，您如何判断“安全”修订版的位置？

这个问题在this question中得到了解决，但我更感兴趣的是如何使用分支回购（而不是命名分支）来解决这个问题。

我了解有一些方法可以修改历史记录（例如collapse extension），以便更改在存储库的历史记录中折叠，但我们希望保留历史记录。

查看mercurial和mozilla树，我看不清楚如何确定安全修订的同步位置。这不像我们想象的那么重要吗？

Answer 1

政治解决方案可能是“不要把垃圾扔进主回购”，不是吗？

技术解决方案无标记，但一个书签（“KnownAsGood”），应用于默认分支的最后一个工作HEAD和开发者之间的协议“更新不要提示，但要标记“

谁将测试提交并移动书签是“项目管理”标签中的另一个问题

Answer 2

你真的需要查看任何旧版本并希望它能够构建吗？

我同意你的意见，你应该能够期待这个小费将永远建立 通过某种“不要将未完成的工作推向主要回购”政策/相互协议，可以很容易地实现like Lazy Badger already said。

关于较旧的修订：

• 如果您想再次构建软件的旧官方版本（例如，您现在的版本为1.6并希望生成v1.2可执行文件），您可以期望构建1.2标记如果每个人都坚持“不要推动未完成的工作”的政策。
• 如果你想采取 ANY 修订并构建它......好吧，你真的需要这个吗？以前版本中的任何错误都可能会引用官方发布（请参阅上面的“1.2标记”），而不是介于两者之间。
• 如果您真的需要在官方发布之间（无论出于何种原因）之间的可构建版本，您将必须查看提交消息并找到提交feature 'foo' finished的提交（而不是那个说started implementation of feature 'foo'）的人 是的，这需要一点思考/常识，但我无法想象你会经常需要这个。

Answer 3

如果您正在使用功能分支并在没有快进合并的情况下合并它们，那么您仍然只能在主线上进行稳定构建，但如果需要，可以在功能分支上看到不稳定的内容。

Answer 4

您可以随时tag提交。这些可能是主要/次要版本，成功构建或您喜欢。您可以在其回购中看到mercurial和mozilla代码。