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

Question

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

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

我的问题是:我们如何处理这样一个事实:由于变更集更加细粒度，这使得开发人员可以更新到未构建的修订版？我们来自一个您可以在存储库中的任何位置 checkout 并合理地期望能够从该点发布的世界。使用 DVCS，您如何判断“安全”修订版在哪里？

此问题在 this question 中有所解决。 ，但我更感兴趣的是找出如何使用分支存储库(而不是命名分支)来处理这个问题。

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

查看mercurial和 mozilla树，我没有看到一个明确的方法来告诉哪里安全修订要同步。这是否没有我们想象的那么重要？

Answer 1

您真的需要检查任何旧版本并期望它能够构建吗？

我同意你的观点，你应该能够预期小费总是会增加。
这很容易实现，like Lazy Badger already said ，通过某种“不要将未完成的工作推送到主仓库”的政策/相互协议(protocol)。

关于旧版本:

• 如果您想再次构建较旧的正式版本的软件(例如，您现在使用的是 1.6 版本并希望制作 v1.2 可执行文件)，则可以使用 1.2 标记如果每个人都始终坚持“不要插入未完成的工作”的政策，那么 build 也同样如此。
• 如果您想进行任何修订并构建它......那么，您真的需要这个吗？以前版本中的任何错误都可能涉及官方版本(请参阅上面的“1.2 标记”内容)，而不是介于两者之间的内容。
• 如果您确实需要官方版本之间的可构建版本(无论出于何种原因)，您必须查看提交消息并找到显示 feature ' 的提交foo'完成(而不是说开始实现功能'foo')。
  是的，这需要一点思考/常识，但我无法想象您会经常需要它。