Mercurial: Pflege der Zweige von Visual Studio 2005 und 2008

Question

Ich versuche, einen Arbeitsablauf zu entwickeln, der es uns ermöglicht, getrennte Visual Studio 2005- und 2008-Versionen einer Bibliothek zu pflegen und gleichzeitig sicherzustellen, dass Änderungen an einem Zweig immer im anderen Zweig repliziert werden.

Im Moment empfehle ich, dass Änderungen immer nur im Standardzweig (VS2005) vorgenommen werden und dann, sobald sie abgeschlossen sind, in den VS2008-Zweig zusammengeführt werden. Leider setzt dies die Disziplin voraus, Probleme nicht einfach zu beheben, wenn sie gefunden werden, und wenn man in der Klemme steckt, kann das schwierig sein. Das hat dazu geführt, dass ich versuchen musste, Änderungen aus einem Zweig zu einem späteren Zeitpunkt wieder in den Standardzweig einzufügen.

Ich weiß, dass wir die Änderungen zwischen dem VS2005- und dem VS2008-Projekt in einer Patch-Warteschlange speichern könnten, aber ich bin der Einzige in meinem Team, der mit der Befehlszeile vertraut ist, meine Kollegen ziehen es vor, alles über Tortoise HG zu erledigen.

Daher bin ich darauf angewiesen, Probleme im Nachhinein zu beheben. Mein derzeitiges Verfahren besteht darin, Patches für jeden Änderungssatz im VS2008-Zweig zu exportieren und sie auf den Standardzweig anzuwenden. Das ist zwar zeitaufwändig, aber viel weniger fehleranfällig als der Versuch, die Spitze des VS2008-Zweigs mit der Spitze des Standardzweigs zusammenzuführen und dann von Hand zurück nach VS2005 zu konvertieren.

Nach der Lektüre dieser Artikel Ich habe versucht, den "Upgrade"-Änderungssatz zurückzunehmen, aber der resultierende Rücknahme-Änderungssatz endet immer als neue Spitze des VS2008-Zweigs, und ich kann die Änderungen nicht wieder einfügen, da die resultierende Zusammenführung im VS2008-Zweig endet, selbst wenn ich versuche, den Zweig bei der Übergabe ausdrücklich zu schließen.

Ich habe versucht, dies in einer Reihe von Möglichkeiten, aber ich immer am Ende mit einem neuen VS2008 Zweig Spitze und keine Möglichkeit, die Änderungen zurück in den Standardzweig zusammenführen. Als solche, ich fange an zu denken, dass ich etwas offensichtlich hier verpasst haben.

Also, letztlich, was andere Leute denken, ist beste Praxis, wenn Sie versuchen, zwei Versionen einer Bibliothek zu pflegen, wo der einzige Unterschied zwischen den beiden sind Visual Studio Versionsnummern, eingebettet in das Projekt und Projektmappen-Dateien wollen?

Edit: Das Problem, das ich zu vermeiden versuche, ist, dass, wenn man ein VS2005-Projekt zu einer VS2008-Lösung hinzufügt (um das Debugging zu erleichtern), das VS2005-Projekt automatisch auf VS2008 "aktualisiert" wird, was zu einer "geänderten" Arbeitskopie und einer Vielzahl von unnötigen "Konvertierungs"-Dateien führt. Damit die Leute nicht in Versuchung kommen, ihr "Upgrade" auf die Hauptversion zu übertragen, ziehe ich es vor, die Zweige getrennt zu halten und den Benutzer aufzufordern, die Version auszuwählen, die er beim ersten Update nach dem Klonen benötigt.

---

Weitere Bearbeitung, mit Lösung.

Nach einigem Herumprobieren habe ich einen Weg gefunden, diesen Arbeitsablauf mit den Standardwerkzeugen von TortoiseHg zu realisieren, so dass ein Eingriff in die Kommandozeile nur noch zum Einrichten erforderlich ist.

Zunächst habe ich auf den Änderungssatz zurückgesetzt, mit dem das Projekt von VS2005 nach VS2008 konvertiert wurde. Ich habe diese Revision zurückgenommen, einen Patch für die zurückgenommene Version erstellt und den zurückgenommenen Änderungssatz entfernt (da er sich im Standardzweig befand). Dann wendete ich den Backout-Patch auf den Konvertierungs-Änderungssatz an (mit: hg patch --no-commit patch) und fügte den Patch mit einem neuen "VS2005"-Zweignamen ein. Dann habe ich die Spitze des (unbenannten) VS2005-Zweigs eingefügt.

Der nächste Schritt bestand darin, auf die alte Spitze des (unbenannten) VS2008-Zweigs zu aktualisieren, eine unbedeutende Änderung vorzunehmen und sie als neuen "VS2008"-Zweig zu übertragen. Dann habe ich die Änderungen aus dem VS2005-Zweig zusammengeführt, aber beim Commit nicht zugelassen, dass die Änderungen an den csproj-Dateien comitted werden. Nach dem Commit habe ich diese Dateien dann rückgängig gemacht.

Schließlich habe ich den VS2005-Tipp aktualisiert und den VS2008-Tipp eingefügt.

Das Ergebnis waren zwei Tipps, beide mit identischem Code, abgesehen von den Unterschieden aufgrund der Konvertierung von VS2005 nach VS2008.

Neuer Arbeitsablauf:

• Arbeiten Sie je nach Bedarf entweder in der VS2005- oder VS2008-Filiale.
• Sobald die Aktualisierungen in einem Zweig abgeschlossen sind, aktualisieren Sie auf den anderen Zweig, führen die Änderungen aus dem geänderten Zweig zusammen und übertragen sie in ihren eigenen Zweig. Aktualisieren Sie dann wieder auf Ihren bevorzugten Zweig.
• Wenn Aktualisierungen in beiden Zweigen gleichzeitig stattfinden, führen Sie beide Zweige getrennt durch, d. h. aktualisieren Sie den VS2005-Tipp und führen Sie ihn mit dem VS2008-Tipp zusammen, aktualisieren Sie dann den VS2008-Tipp und führen Sie ihn mit dem vorherigen (vor der Zusammenführung) VS2005-Tipp zusammen.

Answer 1

Anstatt das Problem zu lösen, könnten Sie versuchen, es zu beseitigen: Versuchen Sie vorbereiten .

Premake ist ein Pre-Build-System (wie der Name schon sagt, ist es dafür gedacht, Pre-Make oder Pre-MSBuild auszuführen, wenn Sie so wollen). Sie beschreiben Ihr Projekt einmal in einer deklarativen internen DSL, die auf der Skriptsprache Lua und premake können automatisch Lösungen und Projekte für VS2008, 2005, 2003 und 2002, MonoDevelop, SharpDevelop, Code::Blocks, CodeLite oder ein GNU Makefile für Unix, Cygwin oder MinGW erzeugen. Es unterstützt derzeit die Erstellung von C++-, C- und C#-Projekten, einschließlich Cross-Compiling für 32/64 Bit, OSX Universal Binaries, PlayStation 3 und XBox 360.

Die Konfigurationssprache ist sehr sauber und deklarativ . Da es jedoch als interne DSL auf Lua aufbaut, haben Sie auch die volle Unterstützung einer sehr mächtigen, schönen, ausdrucksstarken (und vor allem Turing-kompletten) Skriptsprache zur Hand. Sowohl die Struktur als auch die Terminologie der Konfigurationssprache lehnen sich direkt an Visual Studio an: Es geht um Lösungen, Projekte , Konfigurationen y Plattformen .

Das Werkzeug premake selbst ist nur als eine einzige .exe-Datei verteilt die den Lua-Interpreter, die Lua-Standardbibliothek und natürlich das Premake-Skript selbst enthält. Es hat absolut keine externen Abhängigkeiten, schreibt keine Konfigurationsdatei und liest auch nicht die Registry.

Alles, was Sie tun müssen, ist, die VS2008-Lösung in premake zu übersetzen einmal von Hand.

Answer 2

Wir verwenden getrennte Lösungs- und Projektdateien. Wir kopieren die .sln und .csproj/.vcproj/.vbproj und bearbeiten sie in Notepad, um die neuen Dateien zu verwenden. Man muss immer noch daran denken, eine Datei zur anderen Projektmappe hinzuzufügen, wenn man Klassen hinzufügt, aber ansonsten muss man nicht daran denken, die Korrekturen zu kopieren.

Answer 3

Le site Mercurial: Der endgültige Leitfaden Buch hat eine ganzes Kapitel über die Verwendung von Mercurial Patch Queues zur Pflege von Backports für ältere Linux-Kernel. Ich denke, die mq-Erweiterung könnte Ihnen weiterhelfen.

Answer 4

Es scheint ein wenig merkwürdig, meine eigene Frage zu beantworten, aber ohne dies zu tun, kann ich StackOverflow nicht mitteilen, dass diese Frage eine akzeptierte Antwort hat.

Alle Einzelheiten finden Sie in meiner Frage - nach der horizontalen Regel.

Ich sollte mich aber auch für die Antworten der anderen bedanken. Vielleicht finde ich noch eine Verwendung für Premake, und getrennte Projekt-/Lösungsdateien könnten in anderen Situationen funktionieren. Eines Tages werde ich zweifellos selbst eine Verwendung für Mercurial Queues finden, aber ich bezweifle, dass ich jemals den Rest meines Entwicklungsteams dazu bringen werde, sie zu verwenden. Ich habe mich mit Hardlinks unter Windows nie wohl gefühlt, also werde ich das wahrscheinlich nie ausprobieren, aber es ist gut, an ihre Existenz erinnert zu werden.

Passen Sie auf sich auf und nochmals vielen Dank an alle, die sich die Zeit genommen haben, zu antworten.