Best Practice zum Zusammenführen von Lösungsdateien mit Projekt-ID-Konflikten

Question

Angenommen, ein TFS-Zweig wurde aus einem Hauptzweig mit zwei Projekten (FirstNewProject) erstellt, aber während der Arbeit in diesem Zweig noch gearbeitet wurde, wurde ein zweiter Zweig erstellt (SecondNewProject) Die Aufgabe wurde beendet und der andere Zweig wurde wieder zusammengeführt.

Wenn wir jetzt wieder in den Hauptzweig, der erste Zweig zu verschmelzen versuchen, aus denen diese beiden Zweige verzweigt waren wir einen Konflikt in der Lösungsdatei haben jetzt die manuell ... aufgelöst werden scheinbar nur kann

Die Der erste Konflikt ist mit TFS-Variable, die in FirstNewProject und SecondNewProject-Lösungsdateien identisch ist, muss aber geändert werden, um SccNumberOfProjects = 4, denn wenn SecondNewProject zusammengeführt wurde, war die Anzahl der Projekte 3, aber jetzt, dass wir das FirstNewProject die Anzahl von zusammenführen Projekte ist jetzt 4.

Würde diese Variable manuell zu 4 ändern, um ein ungültiges zu erstellen Lösungsdatei?

Der zweite Konflikt befindet sich im globalen Bereich und hat mit der Nummerierung von Projekten zu tun.

SecondNewProject hinzugefügt diese Zeilen Lösung Datei:

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

FirstNewProject diese Zeilen Lösung Datei hinzugefügt:

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

Aber FirstNewProject ist jetzt 4. Projekt so sollten wir diese Einträge zu

ändern

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

manuell und wird das die Lösungsdatei ungültig machen Und gibt es noch etwas zu tun, wenn man in einer Situation wie dieser wieder zusammenfließt?

Answer 1

Ihre Zweigstruktur Unter der Annahme, wie:

FirstNewProject 
/
Main branch 
\ 
SecondNewProject 

Jetzt haben Sie in beiden FirstNewProject und SecondNewProject bearbeitet und wollen FirstNewProject zum Hauptzweig verschmelzen, sowie SecondNewProject. Die SccNumberOfProjects in SecondNewProject ist 3, während SccNumberOfProjects in FirstNewProject 4 ist, so dass Sie verwirren SccNumberOfProjects im Hauptzweig sollte 3 oder 4 sein, richtig?

Ich bin mir nicht sicher, warum Sie gefragt, ändern SccNumberOfProjects würde die Lösungsdatei ungültig machen. Da Sie die Zusammenführung zwischen Hauptzweig und anderen Zweigen durchführen, sollten Quellzweig und Zielzweig identisch sein.

In Bezug auf die Niederlassung und Merge-Strategien sollte ein Grund Zweig Plan aussehen wie der folgende Screenshot zeigt:

Hauptast ist der Knotenpunkt Zweig zwischen der Entwicklung und Zweigen lösen. Dieser Zweig sollte eine stabile Momentaufnahme des Produkts darstellen, die mit QA oder externen Teams geteilt werden kann. Release Branch soll Code in Vorbereitung auf eine Freigabe isolieren. Und alle Änderungen sollten in der Entwicklungsabteilung passieren. Wenn der Code im Zweig Entwicklung gut funktioniert, füge ihn zum Zweig Haupt zusammen. Wenn Sie die Lösung freigeben möchten, führen Sie die Zusammenführung von Hauptzweig zu Zweig freigeben aus.

Für Ihr Szenario müssen Sie prüfen, welcher Zweig Sie möchten, und den Zweig ändern, um den Konflikt zu lösen.Dann können Sie die Filialstrategie verfolgen, um Ihre Filialen zu verwalten.

Answer 2

Merging sln ist schreckliche Erfahrung. Allerdings sehe ich eine andere Lösung für dieses Problem - warum nicht lokale Version beibehalten und dann manuell neues Projekt, um es (von Visual Studio) hinzufügen. Ich weiß, das Handbuch, aber es ist viel weniger fehleranfällig