Best practice per unire i file di soluzione con conflitti di id di progetto

Question

Diciamo che un ramo TFS è stato creato da un ramo principale che aveva 2 progetti (FirstNewProject) ma mentre il lavoro era ancora in corso in quel ramo, è stato creato un altro ramo (SecondNewProject) l'attività era finita e quell'altro ramo era stato ricollegato.

Se ora cerchiamo di unire quel primo ramo di nuovo nel ramo principale da cui entrambi questi rami sono stati ramificata ora abbiamo un conflitto nel file di soluzione che può apparentemente essere risolta solo manualmente ...

Il il primo conflitto è con la variabile T2 SccNumberOfProjects = 3 che è la stessa nei file di soluzione FirstNewProject e SecondNewProject ma deve essere modificata in SccNumberOfProjects = 4 perché quando SecondNewProject è stato unito, il numero di progetti era 3 ma ora che stiamo unendo FirstNewProject il numero di progetti è ora 4.

Cambiare questa variabile manualmente su 4 creare un valore non valido file di soluzione?

Il secondo conflitto si trova nella sezione Globale e ha a che fare con la numerazione del progetto.

SecondNewProject aggiunto queste righe a file di soluzione:

SccProjectUniqueName3 = SecondNewProject\\SecondNewProject.csproj 
SccProjectName3 = SecondNewProject 
SccLocalPath3 = SecondNewProject 

FirstNewProject aggiunto queste righe a file di soluzione:

SccProjectUniqueName3 = FirstNewProject\\FirstNewProject.csproj 
SccProjectName3 = FirstNewProject 
SccLocalPath3 = FirstNewProject 

Ma FirstNewProject è ora 4 ° progetto in modo dovremmo modificare queste voci di

SccProjectUniqueName4 = FirstNewProject\\FirstNewProject.csproj 
SccProjectName4 = FirstNewProject 
SccLocalPath4 = FirstNewProject 

manualmente e ciò renderà non valido il file di soluzione e c'è qualcos'altro da fare quando si ricollega in una situazione come questa?

Answer 1

Assumendo la struttura filiale è come:

FirstNewProject 
/
Main branch 
\ 
SecondNewProject 

Ora è stato modificato in entrambi i FirstNewProject e SecondNewProject, e vogliono fondersi FirstNewProject al ramo principale, così come SecondNewProject. Lo SccNumberOfProjects in SecondNewProject è 3, mentre SccNumberOfProjects in FirstNewProject è 4, quindi si confonde lo SccNumberOfProjects nel ramo Principale dovrebbe essere 3 o 4, corretto?

Non sono sicuro del motivo per cui hai chiesto di modificare SccNumberOfProjects renderebbe il file della soluzione non valido. Poiché si esegue l'unione tra il ramo principale e altri rami, il ramo di origine e il ramo di destinazione dovrebbero essere uguali.

In termini di Branch e Merge strategie, un piano di ramo di base dovrebbe essere simile come la seguente schermata mostra:

ramo principale è il ramo di giunzione tra lo sviluppo e il rilascio rami. Questo ramo dovrebbe rappresentare un'istantanea stabile del prodotto che può essere condivisa con QA o team esterni. Il ramo di rilascio serve per isolare il codice in preparazione di un rilascio. E tutti i cambiamenti dovrebbero avvenire sul ramo Sviluppo. Quando il codice funziona bene nel ramo Sviluppo, uniscilo al ramo Principale. Quando si desidera rilasciare la soluzione, unire dal ramo principale al ramo di rilascio.

Per lo scenario, è necessario verificare quale ramo si desidera e modificare il ramo per risolvere il conflitto.Quindi puoi seguire la strategia della filiale per gestire i tuoi rami.

Answer 2

L'unione di sln è un'esperienza terribile. Tuttavia vedo un'altra soluzione a questo problema: perché non mantenere la versione locale e quindi aggiungere manualmente un nuovo progetto (da Visual Studio). So che questo è manuale ma è molto meno soggetto a errori