TFS 2010: Branching - Perché i changeset dicono che non sono stati uniti quando erano prima del Branch?

Question

Ho creato una filiale e la prima volta che sono passato dall'unione al ramo ci sono stati un sacco di vecchi changeset che dicono che non sono stati uniti ma erano presenti molto prima della filiale e confermo che erano Là.

Esempio: Dire che ho diramato da origine a destinazione quando c'erano 9 changeset in origine. La modifica 10 è stata effettuata in Source. Vado per unire da Source a Target e TFS mi dice che i 6 e 7 e 10 devono essere uniti (anche se 6 e 7 erano lì prima che si ramificasse e posso confermare che questi cambiamenti sono nel Target)

I Sono nuovo a TFS e questo è successo quando ho iniziato a implementare la ramificazione e l'unione. Il ramo più nuovo che ho fatto non lo ha fatto.

In questo momento abbiamo un tronco e quindi 1 ramo per il controllo qualità in corso per la prossima versione e un altro ramo per gli aggiornamenti rapidi alla produzione. Era il ramo QA che aveva questo problema ma quando ho creato il ramo dell'hotfix andava bene.

Answer 1

Mi sono imbattuto in questo poche volte. Alla fine ho semplicemente unito i set-change candidati "canaglia" da sorgente a bersaglio. Ho esaminato la fusione in sospeso e ho stabilito che non c'erano modifiche. L'unione si è liberata di questi gruppi di cambiamento candidati. Ho pensato che avrei potuto tornare indietro se non avesse funzionato.

EDIT: Sembra che se l'aggiornamento a TFS 2010, c'è un bug che causerà i candidati di unione aggiuntivi (vedi http://support.microsoft.com/kb/2135068)

"Tutti gli elementi su un ramo che sono stati rinominati più volte o che hanno ha avuto più altri oggetti occupare il loro spazio dei nomi (attraverso le combinazioni di aggiunta/cancellazione) avrà perso le loro relazioni con gli articoli corrispondenti su altri rami. "

Per quanto riguarda la risoluzione, l'articolo di supporto dice:

"per risolvere il problema con i candidati di unione in più, l'opzione/scarto dovrebbe essere usato per fare questo, eseguire una stampa con il seguente formato da un comando. linea:

tf merge <source branch> <target branch> /r /discard:CXXX~CYYY

in questo esempio, XXX e YYY rappresentano gli ID di changeset del serie di cambiamenti a scartare Dopo questa fusione è stata verificata, i candidati indesiderati non saranno più visualizzati per le unioni futuro anche.. essere consapevoli che, a causa di impr ove previsto nell'algoritmo di fusione in TFS 2010, gli elementi eliminati nei rami di origine e di destinazione determineranno le modifiche da unire. In questi casi, è meglio non scartare i changeset in modo che la cronologia di unione venga aggiornata correttamente. "

Answer 2

L'ho avuto anche alcune volte. Sospetto che la causa sia un po 'strana nel modo in cui TFS gestisce le unioni in sospeso. Se provi a unire queste modifiche, il tipo Cambia è solo" unione "e non" Unisci, modifica ", quindi è sicuro fonderli ed essere sicuri che non si siano verificati cambiamenti. Se non li unisci, TFS continuerà a provare a unire le non modifiche indefinitamente, eventualmente oscurando le modifiche reali alla fine. queste non modifiche APPENA POSSIBILE