Xóa mối quan hệ phân nhánh trong TFS 2010

Question

Tôi có một dự án nhóm TFS 2010 mà tôi vừa mới tiếp quản. Phân cấp phân nhánh là Dev là con của Kiểm tra, Kiểm tra là con của Chính, ví dụ:

Main

----Test

--------Dev

Tuy nhiên tại một số điểm trong một người nào đó trong quá khứ đã làm việc kết hợp với vô căn cứ giữa Dev và Main. điều này gây ra rất nhiều nhầm lẫn khi Nhà phát triển hiện đang vô tình hợp nhất mã trực tiếp từ Dev thành Chính. Điều này gây ra sự đau đớn với các xung đột hợp nhất không lường trước được khi mã tuân theo quy trình chính xác và được hợp nhất từ ​​Kiểm tra tới Chính, cũng như khả năng tạo ra một kịch bản mà mã chưa được kiểm tra được đẩy lên nhánh Chính.

Có cách nào để loại bỏ mối quan hệ phân nhánh giữa Dev và Main mà không xóa chi nhánh không? Tôi muốn giữ nhánh Dev và mối quan hệ của nó với Test. Chỉ cần loại bỏ mối quan hệ với Main.

Tôi đã cố chuyển đổi chi nhánh thành một thư mục để xóa mối quan hệ nhưng điều này không hiệu quả. Tôi có thể sửa lại chi nhánh nhưng dường như không có cách nào rõ ràng để loại bỏ hoàn toàn mối quan hệ. Tôi có thể chuyển đổi các chi nhánh vào một thư mục, sau đó xóa nó và rebranch từ thử nghiệm nhưng điều này sẽ có nghĩa là đảm bảo rằng các codebase được đồng bộ mà có thể khó khăn để đạt được.

Answer 1

TFS không nhất thiết phải xây dựng các ứng viên hợp nhất dựa trên các đối tượng nhánh để tương thích ngược (đối tượng chi nhánh mới trong TFS 2010) và hỗ trợ hợp nhất vô căn cứ (một khi bạn thực hiện kết hợp không căn cứ giữa hai đường dẫn, chúng sẽ được lưu trữ với Tôi muốn đề xuất sử dụng chính sách đăng ký tùy chỉnh ở đây để thực thi việc hợp nhất đó đi từ Dev -> Test hoặc Test -> Dev và không bỏ qua cấp trung gian. Điều này cũng cho phép bạn giữ Dev như một đối tượng chi nhánh, do đó bạn sẽ vẫn có được tất cả các tính năng đẹp như hình ảnh hóa chi nhánh.

Tôi có thể cung cấp một ví dụ rất sơ sài, rất giả về những gì tôi có trong đầu. (Đó là thô cả bởi vì tôi lười biếng và bởi vì tôi dành thời gian của tôi trong SDK Java và không NET SDK. Và tôi nhận ra rằng hầu hết mọi người muốn có một chính sách đăng ký .NET. Nhưng chủ yếu là vì tôi lười biếng.)

/* 
* 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; 
} 

Có một số vấn đề với điều này, tất nhiên. Bạn chắc chắn sẽ không muốn mã hóa danh sách các mối quan hệ hợp nhất có thể chấp nhận được vào chính sách - bạn có thể chuyển nó thành tệp cấu hình hoặc bạn có thể truy vấn các mối quan hệ hợp nhất trên máy chủ và lưu chúng nếu bạn có các quy tắc cụ thể như chỉ con cháu trực tiếp hợp nhất. (Caching điều này rất quan trọng vì việc đánh giá chính sách thường xuyên chạy và được dự kiến ​​là nhanh. Nó thậm chí có thể chạy thỉnh thoảng trên giao diện người dùng (mặc dù tôi nghi ngờ nó), vì vậy số dặm của bạn có thể thay đổi.)

Ngoài ra, đường dẫn thử nghiệm mã là khá cẩu thả, chủ yếu là chỉ để tiết kiệm một số không gian trong bình luận của tôi. (Và ngoài ra, sự lười biếng nói trên của tôi.)

Tôi hy vọng đây là một khởi đầu tốt.

Answer 2

Câu hỏi hay!Tôi không có câu trả lời trực tiếp nhưng tôi có đề xuất giảm nguy cơ xảy ra trong tương lai:

Hạn chế nghiêm ngặt những người có quyền hợp nhất với chi nhánh chính, đặc biệt là chi nhánh chính. Tôi chỉ định một Trưởng nhóm Dev hoặc Sr Dev làm chủ sở hữu chi nhánh chịu trách nhiệm về việc RI kết hợp với chi nhánh đó. (Quản trị viên cũng có thể bao gồm mà không cần thêm đặc quyền.)

Điều này không giúp bạn khi hợp nhất vô căn cứ tạo mối quan hệ mới, nhưng nó sẽ làm giảm nguy cơ tái phát không lường trước trong tương lai. Cũng có thể có trường hợp hợp lệ khi nhảy nhánh Kiểm tra của bạn, nhưng tôi không thể nghĩ ra bất kỳ lý do chính đáng nào để làm như vậy.