我已经在本地使用Mercurial很多年了，但现在我们公司正在尝试从Subversion切换到Subversion。
我们正在接受这样一个事实，即开发人员现在将制作更细粒度的更改集——其中一些甚至可能不会构建。当开发人员将他们的更改推送到中央存储库时，所有这些更改集将显示在历史记录中——这是自然的和预期的。
我的问题是:我们如何处理这样一个事实，因为变更集更细粒度，这使得开发人员有可能更新到一个没有构建的版本?我们所处的时代是这样的:您可以在存储库的任何地方签出，并合理地期望能够从那里发布版本。对于DVCS，你如何判断哪里是"安全"的修改?
这个问题在一定程度上解决了，但我更感兴趣的是如何使用分支仓库(而不是命名分支)来处理这个问题。
我知道有一些方法可以修改历史记录(例如，collapse扩展)，以便更改在存储库的历史记录中被折叠，但我们希望保留历史记录。
看看mercurial和mozilla树，我找不到一个明确的方法来判断哪里是安全的同步版本。这件事没有我们想的那么重要吗?
您真的需要检查任何旧版本并期望它构建吗?
我同意你的观点，你应该能够期待技巧总是会建立起来的。
这很容易实现，就像懒獾已经说过的，通过某种"不要把未完成的工作推到主仓库"的策略/共同协议。
关于旧版本:
- 如果你想再次构建你的软件的旧官方版本(比如，你现在在1.6版本，想做一个v1.2可执行版本)，如果每个人都坚持"不推未完成的工作"的政策，你可以期待
1.2标签的构建。 - 如果你想采用任何版本并构建它…你真的需要这个吗?以前版本中的任何错误都可能会参考官方版本(参见上面的"
1.2标签"内容)，而不是介于两者之间的东西。 - 如果你真的需要一个介于正式版本之间的可构建版本(无论出于什么原因)，你必须查看提交消息并找到说
feature 'foo' finished的提交(而不是说started implementation of feature 'foo'的那个)。是的，这需要一点思考/常识，但我无法想象你会经常需要它。
政治解决方案可能是"不要把垃圾推到主仓库"，不是吗?
技术解决方案将是不是标签，而是一个书签("KnownAsGood")，应用于默认分支的最后一个工作HEAD和开发人员之间的协议"更新不是提示，而是书签"
谁来测试提交和移动书签是来自"项目管理"标签
如果您使用特性分支并合并它们而没有快速向前合并，那么您仍然只有主线上的稳定构建，但是如果需要的话，可以在特性分支上看到不稳定的东西。
你总是可以标记你的提交。这些可以是主要/次要版本，成功的构建或任何你喜欢的。您可以在它们的仓库中看到mercurial和mozilla标签。