Mercurial: Pflege von Visual Studio 2005 und 2008 Filialen

Question

Ich versuche, einen Workflow zu entwickeln, die wir seperate von Visual Studio 2005 und 2008 Versionen einer Bibliothek verwalten kann, gleichzeitig aber dafür sorgen, dass Änderungen an einen Zweig immer in dem anderen Zweig repliziert.

Im Moment empfehle ich, dass Änderungen werden sich immer nur auf den Standardwert (VS2005) Zweig gemacht und dann einmal abgeschlossen ist, in die VS2008 Zweig verschmolzen. Leider verlässt sich dies auf die Disziplin nicht nur Probleme zu beheben, wie und wann sie gefunden werden, und wenn Sie in einem Knirschen sind, kann das schwierig sein. Dies hat dazu geführt, ich von einem Zweig zurück in den Standard zu einem späteren Zeitpunkt nachrüsten Änderungen, um versuchen zu müssen.

Ich weiß, dass wir die Änderungen zwischen dem VS2005 und VS2008-Projekt in einem Patch Warteschlange speichern können, aber ich bin der einzige in meinem Team, die mit der Verwendung der Befehlszeile ist bequem, ziehe meine Kollegen alles obwohl Tortoisehg zu tun .

Als solche verlasse ich mich auf Probleme nach der Tat bis zur Festsetzung. Mein aktuelles Verfahren beinhaltet Patches für jeden changeset im VS2008 Zweig exportieren und auf den Standardzweig anwenden. Dies ist zeitaufwendig, aber viel weniger fehleranfällig als zu versuchen, die Spitze des VS2008 Zweig mit der Spitze des Verzuges und dann Hand Umwandlung zurück in VS2005 von Hand.

zu fusionieren

Nachdem lesen Sie diese Artikel habe ich versucht, rückwärts aus dem ‚Upgrade‘ changeset, aber der resultierende backout changeset endet immer als die neue Spitze des VS2008 Zweig, und ich kann die Änderungen zurück in nicht dann zusammenführen, da die Ende resultierend fusionieren up in dem VS2008 Zweig, auch wenn ich versuche, explizit den Zweig schließen auf begehen.

Ich habe in einer Reihe von Möglichkeiten, um dies versuche zu gehen, aber ich immer mit einer neuen VS2008 Zweigspitze am Ende und keine Möglichkeit, die Änderungen wieder in den Standardzweig zu verschmelzen. Als solches Ich fange an, was ich hier etwas offensichtlich verpasst haben.

Also, schließlich was fühlen Sie anderen Menschen ist beste Praxis, wenn sie versuchen zwei Versionen einer Bibliothek zu erhalten, wo der einzige Unterschied zwischen den beiden Anzeige Visual Studio Versionsnummern sind wollen, eingebettet in die Projekt- und Lösungsdateien?

Edit: Das Problem, das ich zu vermeiden bin versucht, ist, dass, wenn Sie ein VS2005-Projekt zu einer VS2008-Lösung hinzufügen (für eine einfachere Fehlersuche) automatisch ‚Upgrades‘ das VS2005 Projekt VS2008, was zu einer ‚geändert‘ Arbeitskopie und ein Verspritzen von unecessary ‚Konversion‘ Dateien. Also, anstatt die Menschen ihre ‚Upgrade‘ zu begehen versucht wird zu der Hauptstrecke, ziehe ich die Zweige seperate zu halten und muss der Benutzer die Version, die sie auf dem ersten Update benötigen holen nach dem Klon.

---

Weitere bearbeiten, mit der Lösung.

Mit etwas mehr Flickschusterei, fand ich einen Weg, um diese Workflow-Arbeit mit Standard TortoiseHg Tool zu machen, und Intervention Kommandozeile nur benötigte um alles einzurichten.

Zum einen ich zurück zum changeset aktualisiert, in dem das Projekt von VS2005 zu VS2008 umgewandelt wurde. Ich unterstützte diese Revision aus, erstellt einen Patch der backout und gestrippt, um das gesicherte aus changeset (da es im Default-Zweig war). Dann habe ich für den backout Patch auf die Umwandlung changeset (mit: hg Patch --no-commit Patch) und dann comitted den Patch mit einem neuen „VS2005“ Zweignamen. Ich fusionierte dann in der Spitze des (unbenannt) VS2005 Zweig.

Der nächste Schritt war die alte Spitze des (unamed) VS2008 Zweig zu aktualisieren, eine belanglose Änderung vornehmen und sie als neuen „VS2008“ Zweig zu begehen. Ich fusionierte dann in den Veränderungen der VS2005 Spitze, aber wenn ich die Änderungen an den Dateien csproj comitted werden nicht zulassen comitted. Ich kehrte dann diese Dateien nach dem Commit.

Schließlich habe ich auf die VS2005 Spitze aktualisiert und fusionierte in der VS2008 Spitze.

Das in zwei Spitzen geführt, die beide mit identischem Code, mit Ausnahme der Unterschiede aufgrund des VS2005 zu VS2008-Konvertierung.

Neuer Workflow:

• Die Arbeit in entweder VS2005 oder VS2008 Zweig, je nach Bedarf.
• Sobald Updates in einem Zweig, Update auf den anderen Zweig fertig ist, in die Änderungen aus dem modifizierten Zweig zusammenführen und zu seinem eigenen Niederlassung zu begehen. Dann aktualisieren Sie zurück zu Ihrem bevorzugten Zweig.
• Wenn Updates in beiden Zweigen gleichzeitig auftreten, sind beide Zweige separat, das heißt ,. in der vorhergehenden (pre-merge) VS2005 Spitze aktualisieren, um die Spitze und VS2005 in der VS2008 Spitze fusionieren, dann zu aktualisieren, um die Spitze und VS2008 verschmelzen.

Answer 1

Es scheint ein wenig seltsam, meine eigene Frage zu beantworten, aber ohne dies tun kann ich nicht angeben, auf Stackoverflow, dass diese Frage eine Antwort akzeptiert hat.

Für weitere Informationen, meine Frage sehen -. Nach der horizontalen Regel

sollte ich meinen Dank hinzufügen für alle obwohl Antworten elses. Ich kann immer noch eine Verwendung für Premake finden und separate Projekt / Lösung Dateien könnten in anderen Situationen. Einen Tag werde ich zweifellos eine Verwendung für Mercurial Warteschlangen selbst finden, aber ich bezweifle, dass ich jemals den Rest meines Entwicklungsteam erhalten, sie zu nutzen. Ich habe noch nie mit harten Links auf Windows bequem gewesen, so dass ich wahrscheinlich nicht immer, dass es versuchen, aber es ist gut, ihre Existenz erinnert werden.

Achten Sie darauf, und nochmals vielen Dank an alle, die sich die Zeit nahmen reagieren zu können.

Answer 2

Anstatt das Problem zu lösen, könnten Sie versuchen, es weg: versuchen Premake

Premake ist Pre-Build-System (wie der Name schon sagt es beabsichtigt ist, pre-make oder Pre-MSBuild wenn man so will laufen). Sie beschreiben Ihr Projekt einmal in einer deklarativen internen DSL gebaut oben auf der Seite Skriptsprache Lua und Premake können automatisch generieren Lösungen und Projekte für VS2008, 2005, 2003 und 2002, MonoDevelop, SharpDevelop, Code :: Blocks, Codelite oder GNU Makefile für entweder Unix, Cygwin oder MinGW. Es unterstützt derzeit Gebäude C ++, C und C # Projekte, einschließlich Cross-Kompilierung für 32/64 Bit, OSX Universal Binaries, PlayStation 3 und XBox 360.

Die Konfigurationssprache ist sehr sauber und deklarative . Doch als interne DSL oben auf Lua gebaut, haben Sie auch die volle Unterstützung der ein sehr leistungsfähiges, schön, ausdrucksvoll (und vor allem Turing-complete) Skriptsprache zur Hand. Sowohl die Struktur und die Terminologie der Konfigurationssprache auf Visual Studio direkt zu Grunde: es spricht über Lösungen, Projekte , Konfigurationen und Plattformen .

Das Premake Tool selbst ist als nur eine einzige EXE- verteilt, die das Lua-Interpreter enthält, Lua Standard-Bibliothek und natürlich die Premake Skript selbst. Es hat absolut keine externen Abhängigkeiten, keine Konfigurationsdatei schreiben, noch schreibt oder sogar liest nur die Registrierung.

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

Answer 3

Wir verwenden separate Lösung und Projektdateien. Wir kopieren die SLN und CSPROJ / VCPROJ / .vbproj und bearbeiten Sie sie im Editor die neuen Dateien zu verwenden. Sie müssen sich noch daran erinnern, eine Datei an die andere Lösung hinzuzufügen, wenn Klassen hinzufügen, aber ansonsten müssen Sie nicht über die Korrekturen zu kopieren erinnern.

Answer 4

Die Mercurial: The Definitive Guide Buch hat eine ganzes Kapitel zur Verwendung von Mercurial Patch-Queues updates für älteren Linux-Kernel zu halten. Ich denke, die mq Erweiterung helfen könnte, aus.

Answer 5

Vielleicht sollten Sie nicht zwei verschiedene Zweige halten, aber nur einer den Quellcode und die Visual Studio 2005-Projektdateien enthalten. Der zweite Zweig sollte enthält nur die Visual Studio 2008-Projektdateien, nicht schon wieder den Quellcode. Um die Visual Studio 2008-Version kompiliert zu bekommen, erstellen harte Links auf dem lokalen Laufwerk für alle Quelldateien, um sie in beiden Ordner-Strukturen (legen Sie die Hardlink Schöpfung in einer Batch-Datei zusammen mit den Befehlen für immer die neuesten Updates aus dem Repository erscheinen ). Für diesen Ansatz müssen Sie NTFS-Dateisystem und ein entsprechendes „ln“ Kommandozeilen-Tool, zum Beispiel dieses .

So können Sie / Debuggen von Quellcode bearbeiten entweder Ordner, den Sie möchten, werden alle Änderungen sofort angezeigt in den anderen Ordner auch.

Edit: und ja, ich habe versucht, dass von mir, es funktioniert. Wir haben ein sehr ähnliches Szenario, eine C ++ Anwendung mit Visual Studio 2008 und ein älteren Borland-Compiler kompiliert werden.