达尔克冲突
我几天前安装了 Darcs，但有一个疑问。 我是唯一的程序员，我通常在应用程序的两个或三个实例上工作，制作新功能。 问题的出现是因为这个实例修改了相同的源代码文件，所以当我完成它们并将其发送到主存储库时，它们会产生冲突。 有什么办法可以解决这个问题吗？ 我可以在多个实例中写入相同的文件，而不会在推送到主存储库时发生冲突吗？ 谢谢
I installed Darcs a few days ago and have a doubt.
I am the only programmer and I usually work on two or three instances of the application, making new feautures. The problems cames because this instances modify the same source code file, so when I finished them and send to main repository they make a conflict.
Is there any way to deal with this? Can I write the same file in multiple instances without making conflict when pushing to main repository?
thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先，当文件的不同位置发生更改时，合并时通常不会发生冲突。 当两个补丁可以无冲突地合并时，就可以说它们是可通勤的。 在您的情况下，您恰好在两个不同的分支中修改了文件的相同部分。 在这种情况下，darcs 不允许您“推送”造成冲突的第二个补丁。
有两种方法可以解决此类冲突，但您必须开始在本地合并这两个补丁才能在工作存储库中解决冲突。 为此，只需从主存储库中提取补丁即可。 然后您必须编辑有问题的文件并解决冲突。
第一种方法很简单，也是首选的解决方案，您必须“修改记录”主存储库上尚未存在的补丁（查看“darcs amend-record”命令的用法）。
另一种解决方案是通过调用“darcs record”来记录解决补丁，然后推送冲突补丁和解决补丁。 此解决方案往往会使历史记录变得复杂，并且可能会使后续的一些操作变得更长。 然而，当分支分布广泛时，就需要这种解决方案。
First of all when changes occurs at different places of the file there is generally no conflicts when merging. When two patches can be merged without conflicts one says that they commute. In your case it happens that you've modified the same part of the file in two different branches. In this case darcs don't allow you to "push" the second patch that makes the conflict.
There is two ways to resolve such a confilct, but you have to start to locally merge the both patches to get the conflict in your working repo. To do this just pull the patches from the main repository. Then you have to edit the offended file and resolve the conflict.
The first way is simple and the prefered solution, you have to "amend-record" the patch that is not yet on the main repository (look at the usage of the "darcs amend-record" command).
The other solution is to record a resolution patch, by calling "darcs record" and then pushing both the conflicting patch and the resolution patch. This solution tends to complicate the history and can make some later operations longer. However when the branch has been heavily distributed this solution becomes needed.