在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.

Main

----测试

-------- Dev

但是在过去的某个时候，有人在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进行合并时，这将导致无法预料的合并冲突，并可能导致未经测试的代码升级为以下情况：

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不一定基于分支对象构建合并候选对象以实现向后兼容性（分支对象是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或测试->开发，不要跳过中间级别。这还允许您将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签入策略。但是主要是因为我很懒。） / p>

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屋！