对于使用 Mercurial 的非开发人员来说最简单的工作流程，可以处理不同的文件，而无需考虑合并？
我目前使用 SVN 来处理许多不完全是代码的事情，例如 xml 文件、报告模板、杂项文件等。我有几个非开发人员可以轻松地使用 TortoiseSVN 来完成此任务。他们通常的工作方式如下：
人员 A - 对他们感兴趣的文件夹进行 SVN 更新。或者可能只是在单个文件上。
人员 A - 编辑他们正在处理的任何文件。也许添加或删除文件。
人员 B - 此时其他人可能正在处理不同的文件
人员 A - 进行 SVN 提交以将其更改保存到存储库。
极少数情况下，他们会遇到多个人编辑文件的冲突。这几乎总是因为他们忘记了第一步。因为他们总是处理单独的文件，所以（几乎）从来没有真正的冲突。只要他们首先执行步骤#1，一切都会正常。
我想迁移到 Mercurial，但是阻碍我的是始终进行“合并”的前景，因为 Mercurial 会查看整个存储库的状态，而不仅仅是特定时间感兴趣的文件。例如，工作流程将如下所示：
人员 A - 在存储库上进行拉取和更新。 （假设没有本地更改，因此这很简单）。
人员 A - 编辑他们正在处理的任何文件。也许添加或删除文件。
B 人 - 此时其他人编辑、提交并推送不同的文件
A - 提交更改。试图推动。获取有关多个头的错误。
A 人 - 进行拉取和更新。更新不起作用：需要合并。
A 人 - 进行合并。如果使用 TortoiseHg，那么确定单击什么来进行合并会有点混乱。我想这在命令行上会更简单，只要没有复杂性。
人员 A - 提交合并。
A - 推送更改。
我的反对意见是步骤太多，而且如果您不是开发人员，合并步骤有点难以理解。有没有办法可以将这些步骤放在一起，使整个过程变得既美好又简单？
I currently use SVN for a number of things that aren't exactly code, for instance xml files, report templates, miscellaneous files, etc. I have several non-developers who are comfortable using TortoiseSVN for this. They typically work as follows:
Person A - does an SVN Update on the folder of interest to them. Or perhaps just on a single file.
Person A - edits whichever file(s) they're working on. Perhaps add or remove files.
Person B - someone else is probably working on different files at this point
Person A - does an SVN Commit to save their changes to the repository.
Very occasionally they'll hit conflicts where more than one person has edited a file. Almost always this is just because they forgot step #1. Because they're always working on separate files, there are (almost) never real conflicts. As long as they do step #1 first everything works fine.
I'd like to move to Mercurial, however something holding me back is the prospect of having do 'merge' all the time, because Mercurial looks at the state of the entire repository, not just the files of interest at a particular time. e.g. the workflow would be like this:
Person A - does a pull and update on the repository. (let's assume there are no local changes so this is straightforward).
Person A - edits whichever file(s) they're working on. Perhaps add or remove files.
Person B - someone else edits, commits, and pushes a different file at this point
Person A - commits changes. Tries to push. Gets an error about multiple heads.
Person A - does a pull and update. update doesn't work: merge required.
Person A - does a merge. If using TortoiseHg it's a bit confusing working out what to click on to do the merge. I guess this is simpler on the command line, provided there are no complications.
Person A - commits the merge.
Person A - pushes the changes.
My resistance is that there are more steps, and the merge step is somewhat hard to get your head around if you're not a developer. Is there a way I can put these steps together to make the process nice and simple?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
“极少数情况下，他们会遇到多个人编辑文件的冲突。这几乎总是因为他们忘记了第 1 步。因为他们总是处理单独的文件，所以（几乎）永远不会出现真正的冲突。只要他们首先执行第 1 步，一切都会正常。”
如果是这种情况，您为什么要使用 DVCS？ Mercurial 很棒，但 DVCS 的好处来自于合并和分叉的能力以及两者的简便性，如果您的工作流程两者都不需要，为什么要切换工具集呢？
"Very occasionally they'll hit conflicts where more than one person has edited a file. Almost always this is just because they forgot step #1. Because they're always working on separate files, there are (almost) never real conflicts. As long as they do step #1 first everything works fine."
If this is the case why do you want to use a DVCS? Mercurial is great, but the benefits of a DVCS come from the ability to merge and fork and the ease of doing either, if your workflow requires neither why would you want to switch toolset?
听起来 rebase 扩展可能适合您。工作流程变为：
本地修订将“重新基于”到拉取的最新提示上，这避免了合并。
Sounds like the rebase extension might work for you. The workflow becomes:
The local revisions get "rebased" onto the latest tip on pull, which avoids the merge.
一种可能的方法是指定一名核心人员来完成所有实际的合并工作。我不太喜欢让每个人都推送到一个共享存储库，特别是如果他们不知道自己在做什么的话。另一种方法是，A 有本地存储库 A，B 有本地存储库 B，还有存储库 S，它结合了 A 和 B。然后，不要让 A 或 B 推送到 S。而是让专家从 A 中拉取，然后B，并在 S 中进行合并。然后 A 和 B 永远不必推送到 S。如果他们与专家协调，那么当他们从 S 中提取更新时，他/她已经将他们的更改合并到 S 中，所以A 和 B 在拉动时也不必合并。这实际上是 DVCS 工作的默认模式，因为默认情况下，除了其所有者之外，所有存储库都是只读的。
One possible approach is to have a point person who does all the real work of merging. I'm not a big fan of letting everyone push to one shared repos, expecially if they don't know what they are doing. An alternative approach is that A has local repos A, B has local repos B, and there is repos S, which combines A and B. Then, don't let A or B push to S. Instead let an expert pull from A and B, and do the merging in S. Then A and B never have to push to S. If they coordinate with the expert, then he/she will already have merged their changes into S by the time they pull updates from S, and so A and B will not have to merge either when pulling. This is actually the default mode in which DVCS works, since by default all repositories are read-only except by their owner.