使用mercurial的非开发人员最简单的工作流程，处理不同的文件，而不必考虑合并？

Question

我目前使用SVN进行许多不完全代码的事情，例如xml文件，报告模板，杂项文件等。我有几个非开发人员，他们很乐意使用TortoiseSVN。它们通常如下工作：

1. 人员A - 对他们感兴趣的文件夹进行SVN更新。或者也许只是在一个文件上。

2. 人员A - 编辑他们正在处理的文件。也许添加或删除文件。

3. B人 - 此时其他人可能正在处理不同的文件

4. Person A - 做SVN提交将其更改保存到存储库。

偶尔他们会遇到多个人编辑文件的冲突。几乎总是这只是因为他们忘记了第一步。因为他们总是处理单独的文件，所以（几乎）从不真正的冲突。只要他们做第一步，一切都运转正常。

我想转移到Mercurial，不过有些让我失望的是一直在进行'合并'的前景，因为Mercurial会查看整个存储库的状态，而不仅仅是感兴趣的文件。时间。例如工作流程将是这样的：

1. 人员A - 对存储库进行提取和更新。 （我们假设没有局部变化，所以这很简单。）

2. 人员A - 编辑他们正在处理的文件。也许添加或删除文件。

3. B人 - 其他人在此时编辑，提交和推送不同的文件

4. 人员A - 提交更改。试图推动。获取有关多个头的错误。

5. 人A - 进行拉动和更新。更新不起作用：需要合并。

6. 人A - 进行合并。如果使用TortoiseHg，有点令人困惑的是找出点击进行合并的内容。我想这在命令行上更简单，只要没有并发症。

7. Person A - 提交合并。

8. 人A - 推动变化。

我的阻力是，有更多的步骤，如果你不是开发人员，合并步骤有点难以理解。有没有办法将这些步骤放在一起，使这个过程变得简单明了？

Answer 1

听起来像rebase extension可能适合你。工作流程变为：

• hg clone
• 进行更改
• hg commit
• hg pull --rebase
• hg push

本地修订在“拉动”的最新提示上“重新定位”，这避免了合并。

Answer 2

“非常偶尔他们会遇到不止一个人编辑文件的冲突。几乎总是这只是因为他们忘记了第1步。因为他们总是处理单独的文件，所以（几乎）从不真实冲突。只要他们做第一步，一切都运转良好。“

如果是这种情况，您为什么要使用DVCS？ Mercurial很棒，但如果您的工作流程既不需要切换工具集也不需要切换工具集，那么DVCS的好处来自于合并和分叉的能力以及易于执行的任务？

Answer 3

一种可能的方法是让一个有能力完成所有合并工作的人。我不是让每个人都推到一个共享回购的忠实粉丝，特别是如果他们不知道他们在做什么的话。另一种方法是A有本地回购A，B有本地回购B，有回购S，它结合了A和B.然后，不要让A或B推到S.而是让专家从A和B，并在S中进行合并。然后A和B永远不必推送到S.如果他们与专家协调，那么他/她将在他们从S提取更新时将他们的更改合并为S，所以拉动时A和B也不必合并。这实际上是DVCS工作的默认模式，因为默认情况下所有存储库都是只读的，除非是它们的所有者。