时间戳

首页 > 解决方案 > Tfs / AzureDevOps 客户端库合并 AzureDevOps 分支上的冲突解决

c# - Tfs / AzureDevOps 客户端库合并 AzureDevOps 分支上的冲突解决

问题描述

我编写了一些 c# 代码，旨在自动化相关 tfvc 分支之间的 AzureDevOps 合并，从而尝试使它们保持同步（不执行无根据的合并）。

这是通过依赖位于Microsoft.TeamFoundationServer.ExtendedClient和Microsoft.TeamFoundationServer.ClientNuGet 包中的客户端库来实现的。

代码使用 Workspace 类中的“Merge”方法Microsoft.TeamFoundation.VersionControl.Client：

GetStatus status = workspace.Merge(sourceBranch,
                               destinationBranch,
                               vsFromChangeset,
                               vsToChangeset,
                               LockLevel.None,
                               RecursionType.Full,
                               MergeOptions.None); 

int numberOfConflicts = status.NumConflicts;

合并完成后，我检查“GetStatus”对象上的 NumConflicts 字段的状态，以确定是否发生合并冲突。如果确实如此，我会停止该过程，并且需要手动解决这个特定的合并问题——即在 Visual Studio 中合并（我使用 VS2017 Prof）。这并不是什么大问题，因为从自动合并确实成功的时代获得的生产力就足够了。

我无法解释的奥秘是：

在大多数情况下，当客户端库合并指示合并冲突，然后通过 Visual Studio 完成合并时，Visual Studio 会在没有提及合并冲突的情况下执行此操作。没问题。

似乎 Visual Studio 中有一个额外级别的“合并冲突解决逻辑”，使其能够执行更高级类型的合并冲突解决，而不是客户端库？但我可能在这里偏离了目标

也就是说，MergeOptionsEnum 的用法（如这里所解释的）对我来说并不完全清楚，所以这可能是导致头痛的原因。任何详细说明该主题的资源将不胜感激。MergeOptions 当前设置为none，这适用于大多数情况。

关于导致这种行为的任何想法？谢谢！

标签： c#tfsazure-devopstfvctfs-sdk

解决方案

此问题已通过更改 Microsoft.TeamFoundation.VersionControl.Client.Workspace 类的 Merge 方法中使用的 mergeOptions 参数得到解决。

使用枚举 Microsoft.TeamFoundation.VersionControl.Common.MergeOptionsEx 而不是Microsoft.TeamFoundation.VersionControl.Client.MergeOptions 上的合并选项为我解决了这个问题。

我现在已经看到 80 多个自动合并完美地工作，并且不再有以前的不稳定行为。合并命令应如下所示：

GetStatus status = workspace.Merge(sourceBranch,
                           destinationBranch,
                           vsFromChangeset,
                           vsToChangeset,
                           LockLevel.None,
                           RecursionType.Full,
                           MergeOptionsEx.None);

所以我的问题的答案就在无名英雄 Mariusz Skoczylas的一篇 social.msdn帖子的底部。非常感谢！

MergeOptionsEx 的官方文档可以在这里找到

推荐阅读