Rimuovere una relazione di diramazione in TFS 2010

Question

Ho un progetto di squadra TFS 2010 che ho appena rilevato. La gerarchia di ramificazione è Dev è un figlio di Test, Test è un figlio di Main ad es.

Main

----Test

--------Dev

Tuttavia ad un certo punto, in passato qualcuno ha fatto una fusione senza fondamento tra Dev e Main. questo sta causando molta confusione poiché gli sviluppatori ora stanno accidentalmente unendo il codice direttamente da Dev a Main.

Ciò causa dolore con conflitti di unione imprevisti quando il codice segue il processo corretto e viene unito da Test a Principale, oltre a creare potenzialmente uno scenario in cui il codice non testato viene promosso al ramo Principale.

C'è un modo per rimuovere la relazione di diramazione tra Dev e Main senza eliminare il ramo? Vorrei mantenere il ramo Dev e la sua relazione con Test. Basta rimuovere la relazione con Main.

Ho provato a convertire il ramo in una cartella per rimuovere le relazioni ma questo non funziona. Posso riparare il ramo ma non sembra esserci alcun modo ovvio per rimuovere completamente la relazione. Potrei convertire il ramo in una cartella, quindi cancellarlo e riarrangiarlo da Test, ma ciò significa che ci si assicura che il codebase sia sincronizzato e che potrebbe essere difficile da ottenere.

Answer 1

TFS non crea necessariamente unire candidati basati su oggetti ramo per compatibilità all'indietro (gli oggetti ramo erano nuovi in ​​TFS 2010) e per supportare fusioni senza fondamento (una volta eseguita un'unione baseless tra due percorsi, questi verranno archiviati con un unire la relazione per future unioni.)

Suggerirei di utilizzare una politica di check-in personalizzata qui che impone che le unioni passino da Dev -> Test o Test -> Dev e non saltare il livello intermedio. Questo ti permette anche di mantenere Dev come un oggetto branch, così avrai comunque tutte le caratteristiche gradevoli come la visualizzazione branch.

Posso fornire un esempio molto approssimativo, molto pseudo-cody, di ciò che avevo in mente. (È dura sia perché sono pigro, sia perché trascorro il mio tempo nell'SDK Java e non nell'SDK .NET e mi rendo conto che la maggior parte delle persone desidera una politica di archiviazione .NET. Ma soprattutto perché sono pigro.)

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

Ci sono diversi problemi con questo, ovviamente. Certamente non vorrete codificare l'elenco delle relazioni di fusione accettabili nella politica: potreste esternalizzarlo in un file di configurazione, oppure potete interrogare le relazioni di fusione sul server e memorizzarle nella cache se avete regole particolari come solo i discendenti diretti possono fondersi. (La memorizzazione nella cache di questa operazione è importante poiché la valutazione della politica di check-in viene eseguita frequentemente e dovrebbe essere veloce. Può anche essere eseguita occasionalmente sul thread dell'interfaccia utente (sebbene ne dubiti), quindi il tuo chilometraggio può variare.)

Inoltre, my il codice di test del percorso è piuttosto sciatto, principalmente solo per risparmiare spazio nel mio commento. (E anche, la pigrizia di cui sopra da parte mia.)

Spero che questo sia un buon inizio.

Answer 2

Ottima domanda!Non ho la risposta diretta, ma ho il suggerimento di ridurre il rischio di eventi futuri:

Limitare severamente chi ha i diritti per unire i rami padre, in particolare per il ramo Principale. Ho designato un Dev Lead o Sr. Dev come proprietario di una filiale che è responsabile per il RI si fonde con quella filiale. (Gli amministratori possono anche coprire senza richiedere privilegi aggiuntivi.)

Ciò non aiuta l'utente una volta che l'unione senza base crea una nuova relazione, ma dovrebbe ridurre il rischio di ricorrenza non intenzionale in futuro. Potrebbe anche esserci un caso valido in cui sarebbe necessario saltare il ramo Test, ma non riesco a pensare a nessuna buona ragione per farlo.