Tfs / Azure DevOps 客户端库在 Azure DevOps 分支上合并冲突解决
Tfs / AzureDevOps client libraries merge conflict resolution on AzureDevOps branches
我编写了一些 c# 代码,旨在自动执行相关 tfvc 分支之间的 AzureDevOps 合并,从而尝试使它们保持同步(不执行无根据的合并)。
这是通过 Microsoft.TeamFoundationServer.ExtendedClient
和 Microsoft.TeamFoundationServer.Client
NuGet 包中的客户端库实现的。
代码在 Microsoft.TeamFoundation.VersionControl.Client
:
中的工作区 class 上使用“合并”方法
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 中有一个额外级别的“合并冲突解决逻辑”,使其能够执行与客户端库相反的更高级类型的合并冲突解决?
但我可能离题太远
就是说,MergeOptions
枚举的用法(如 here 所解释的)对我来说并不完全清楚,所以这可能就是令人头疼的原因。任何详细阐述该主题的来源将不胜感激。 MergeOptions 当前设置为 none,适用于大多数情况。
关于导致此行为的原因有什么想法吗?
谢谢!
此问题已通过更改 Microsoft.TeamFoundation.VersionControl.Client.Workspace class 上 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);
所以我的问题的答案就在 social.msdn post 的底部由无名英雄 Mariusz Skoczylas 找到了。非常感谢!
可以找到 MergeOptionsEx 的官方文档here
我编写了一些 c# 代码,旨在自动执行相关 tfvc 分支之间的 AzureDevOps 合并,从而尝试使它们保持同步(不执行无根据的合并)。
这是通过 Microsoft.TeamFoundationServer.ExtendedClient
和 Microsoft.TeamFoundationServer.Client
NuGet 包中的客户端库实现的。
代码在 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 中有一个额外级别的“合并冲突解决逻辑”,使其能够执行与客户端库相反的更高级类型的合并冲突解决? 但我可能离题太远
就是说,MergeOptions
枚举的用法(如 here 所解释的)对我来说并不完全清楚,所以这可能就是令人头疼的原因。任何详细阐述该主题的来源将不胜感激。 MergeOptions 当前设置为 none,适用于大多数情况。
关于导致此行为的原因有什么想法吗? 谢谢!
此问题已通过更改 Microsoft.TeamFoundation.VersionControl.Client.Workspace class 上 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);
所以我的问题的答案就在 social.msdn post 的底部由无名英雄 Mariusz Skoczylas 找到了。非常感谢!
可以找到 MergeOptionsEx 的官方文档here