Tfs / AzureDevOps client libraries merge conflict resolution on AzureDevOps branches

Question

I have written some c# code that aims to automate AzureDevOps merges between related tfvc branches, thereby attempting to keep them in sync (no baseless merges are performed).

This is achieved by relying on the client libraries located in the Microsoft.TeamFoundationServer.ExtendedClient and Microsoft.TeamFoundationServer.Client NuGet packages.

The code uses the “Merge” method on the Workspace class within the Microsoft.TeamFoundation.VersionControl.Client:

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

int numberOfConflicts = status.NumConflicts;

After the merge was completed I check the status of the NumConflicts field on the “GetStatus” object to determine if a merge conflict occurred. If this is indeed the case, I stop the process and this particular merge needs to be resolved manually – i.e. merged within Visual Studio (I use VS2017 Prof). This is not really a big deal as the productivity gained from the times that the automatic merge was indeed successful, is sufficient.

The mystery that I am unable to explain is:

In most cases when the client libraries merge indicates a merge conflict, and the merge is then done via Visual Studio, Visual Studio does it without any mention of a merge conflict. No problem what so ever.

It almost seems as if there is an extra level of “merge conflict resolution logic” within Visual Studio that enables it to do a more advanced type of merge conflict resolution as opposed to the client libraries? But I am probably way off the mark here 😊

That said, the usage of the MergeOptions Enum (as explained here), is not entirely clear to me, so maybe that is the cause of the headache. Any source that elaborates more on the topic would be greatly appreciated. The MergeOptions is currently set to none, and that works for most cases.

Any ideas on what causes this behavior? Thanks!

Answer 1

This problem was resolved by changing the mergeOptions parameter used in the Merge method on the Microsoft.TeamFoundation.VersionControl.Client.Workspace class.

Using the merge options on the enum Microsoft.TeamFoundation.VersionControl.Common.MergeOptionsEx instead of Microsoft.TeamFoundation.VersionControl.Client.MergeOptions solved the issue for me.

I have now seen 80+ automatic merges work perfectly and no more of the previous erratic behavior. The merge command should look like this:

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

So the answer to my problem was found right at the bottom of a social.msdn post by the unsung hero Mariusz Skoczylas. Many thanks!

The official documentation on MergeOptionsEx can be found here