删除 TFS 2010 中的分支关系 [英] Remove a Branching Relationship in TFS 2010

问题描述

我有一个刚刚接手的 TFS 2010 团队项目.分支层次结构是 Dev 是 Test 的子级，Test 是 Main 的子级，例如

I have a TFS 2010 Team Project that I've just taken over. The branching hierarchy is Dev is a child of Test, Test is a child of Main e.g.

主要

----测试

--------开发

然而，在过去的某个时候，有人在 Dev 和 Main 之间进行了毫无根据的合并.这引起了很大的混乱，因为开发人员现在不小心将代码直接从 Dev 合并到 Main.

However at some point in the past someone has done a baseless merge between Dev and Main. this is causing a great deal of confusion as Developers are now accidentally merging code directly from Dev to Main.

当代码遵循正确的流程并从 Test 合并到 Main 时，这会导致无法预料的合并冲突带来痛苦，并且可能会造成将未经测试的代码提升到 Main 分支的场景.

This is causing pain with unforeseen merge conflicts when code follows the correct process and is merged from Test to Main, as well as potentially creating a scenario where untested code is promoted to the Main branch.

有什么办法可以在不删除分支的情况下去掉Dev和Main之间的分支关系?我想保留 Dev 分支以及它与 Test 的关系.只需删除与 Main 的关系即可.

Is there any way to remove the branching relationship between Dev and Main without deleting the branch? I would like to keep the Dev branch and it's relationship with Test. Just remove the relationship with Main.

我尝试将分支转换为文件夹以删除关系，但这不起作用.我可以重新设置分支，但似乎没有任何明显的方法可以完全消除这种关系.我可以将分支转换为文件夹，然后将其删除并从 Test 重新分支，但这意味着确保代码库同步，这可能难以实现.

I've tried to convert the branch to a folder to remove the relationships but this doesn't work. I can reparent the branch but there doesn't seem to be any obvious way to remove the relationship completely. I could convert the branch to a folder, then delete it and rebranch from Test but this will mean making sure that the codebase is synchronised which may be difficult to achieve.

推荐答案

为了向后兼容(分支对象是 TFS 2010 中的新对象)和支持无基础合并(一旦你执行两条路径之间的无根据合并，这些路径将与合并关系一起存储，以备将来合并.)

TFS doesn't necessarily build merge candidates based on branch objects for backwards compatibility (branch objects were new in TFS 2010) and to support baseless merges (once you perform a baseless merge between two paths, those will be stored with a merge relationship for future merges.)

我建议在此处使用自定义签入策略，强制合并从 Dev -> Test 或 Test -> Dev 进行，不要跳过中间级别.这还允许您将 Dev 作为分支对象保留，因此您仍将获得所有不错的功能，例如分支可视化.

I'd suggest using a custom check-in policy here that enforces that merges go from Dev -> Test or Test -> Dev and don't skip the intermediate level. This also allows you to keep Dev as a branch object, so you'll still get all the nice features like branch visualization.

我可以提供一个非常粗略、非常伪代码的示例来说明我的想法.(这很粗糙，因为我很懒，而且因为我把时间花在 Java SDK 而不是 .NET SDK 上，我意识到大多数人都想要 .NET 签入策略.但主要是因为我很懒.)

I can provide a very rough, very pseudo-codey example of what I had in mind. (It's rough both because I'm lazy and because I spend my time in the Java SDK and not the .NET SDK and I realize that most people want a .NET check-in policy. But mostly because I'm lazy.)

/*
 * Create a dictionary of merge targets to allowable merge sources.
 * For an item in this list, the allowable merge sources are a whitelist.
 */
private readonly Dictionary<String, List<String>> restrictedMergeTargets =
    new Dictionary<String, List<String>>();

public static MergeWhitelistPolicy
{
    /* Only allowed merges to $/Main from $/Test. */
    List<String> mainWhitelist = new List<String>();
    mainWhitelist.add("$/Test");
    allowedMerges.put("$/Main", mainWhitelist);

    /* Only allow merges to $/Test from $/Dev. */
    List<String> testWhitelist = new List<String>();
    testWhitelist.add("$/Dev");
    allowedMerges.put("$/Test", testWhitelist);
}

public PolicyFailure[] evaluate(PolicyContext context)
{
    PendingChange[] pendingChanges = GetPendingCheckin().GetCheckedPendingChanges();

    foreach(PendingChange change : pendingChanges)
    {
        if(! change.IsMerge())
        {
            continue;
        }

        foreach(KeyValuePair<String, List<String>> restrictedTarget : restrictedMergeTargets)
        {
            if(VersionControlPath.IsChild(restrictedTarget.GetKey(), change.GetServerItem())
            {
                /* Whitelisted merge path - investigate. */
                foreach(String allowedSource : restrictedTarget.GetValue())
                {
                    foreach(MergeSource mergeSource : change.GetMergeSources())
                    {
                        if(! VersionControlPath.IsChild(allowedSource, mergeSource.GetServerItem()))
                        {
                            return new PolicyFailure("Merge from " +
                                mergeSource.GetServerItem() + " to " +
                                change.GetServerItem() + " is disallowed.");
                        }
                    }
                }
            }
        }
    }

    return null;
}

当然，这有几个问题.您当然不想将可接受的合并关系列表硬编码到策略中 - 您可以将其外部化到配置文件中，或者您可以查询服务器上的合并关系并缓存它们，如果您有特定规则，例如只有直接后代可以合并.(缓存这一点很重要，因为签入策略评估运行频繁并且预计会很快.它甚至可能偶尔在 UI 线程上运行(尽管我对此表示怀疑)，因此您的里程可能会有所不同.)

There are several issues with this, of course. You certainly wouldn't want to hardcode the list of acceptable merge relationships into the policy - you could externalize it into a configuration file, or you could query the merge relationships on the server and cache them if you had particular rules like only direct descendants can merge. (Caching this is important as check-in policy evaluation runs frequently and is expected to be fast. It may even run on the UI thread occasionally (though I doubt it), so your mileage may vary.)

另外，我的路径测试代码非常草率，主要是为了在我的评论中节省一些空间.(还有，前面提到的我的懒惰.)

Also, my path testing code is pretty sloppy, mostly just to save some space in my comment. (And also, the aforementioned laziness on my part.)

我希望这是一个好的开始.

I hope this is a good start.

这篇关于删除 TFS 2010 中的分支关系的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！