Zusammenführen vcproj-Dateien - SCM-Hölle
Merging project/solution Dateien ist eine bekannte Katastrophe unter den Entwicklern/SCM-admins durchführen verschmilzt in Ihren source-control.
Nehmen, zum Beispiel, ein häufiges Szenario: die Entwicklung geschieht auf einem Projekt/die Lösung in zwei verschiedenen Filialen. Wenn die Zeit kommt zu verschmelzen, zurück in die Haupt-Entwicklungslinie, es ist eine sehr kleine ähnlichkeit zwischen den VCPROJ (und SLNs).
Der Grund ist, dass Visual Studio ändern können (und ändern) Lage der verschiedenen XML-Elemente innerhalb dieser Dateien. E. g., Die Konfigurationen Debug und Release können tauschen, um bei jedem speichern-Vorgang auf der proj-Datei. Diese macht es möglich, leicht einarbeiten von änderungen aus jedem Zweig, nicht einmal in Erwägung ziehen, eine automatische Zusammenführen.
Kann ich davon ausgehen, dass Microsoft einige perl-Hash-system, um zu halten die vcproj-Strukturen, also die Darstellung der Dateien beim speichern-operation wird nicht bestellt.
Ich würde zunächst gerne Fragen: hat jemand gefunden, einige elegante Methode zur Umgehung dieses?
Zweiten, ich würde gerne zwei Vorschläge:
-
Microsoft bitte implementieren Sie die oben genannten Dateien und verhindern, dass Sie an einen festen Reihenfolge der Elemente.
-
ein tool finden (oder selbst schreiben), die möglichen vcproj (xml-format) und sln (sln format...) Dateien alphabetisch, rekursiv (alle Elemente innerhalb von Elementen etc.). Mit diesem tool auf dem Quell-und Ziel-Dateien, die es ermöglichen würde leicht zu zeigen (und Zusammenführen) die änderungen, in der Hoffnung, dass Visual Studio liest, sortiert, zusammengeführt Projekt oder die sln-Datei.
Andere Ideen und Gedanken sind willkommen.
- Ich mag Ihre tool-Idee. es scheint mir eine sinnvolle Sache zu haben. Vielleicht werde ich mal einen es...
- Wie zuversichtlich sind Sie, dass die Reihenfolge der Elemente keine Bedeutung in der Lösung von Dateien? Sagen wir, innerhalb der ProjectSection(ProjectDependencies) und GlobalSection(TeamFoundationVersionControl) Abschnitte? Gibt es ein veröffentlichtes format irgendwo?
Du musst angemeldet sein, um einen Kommentar abzugeben.
Es wurde ein tool zum vergleichen und Zusammenführen Lösung Datei (http://slntools.codeplex.com). Es ist viel einfacher Zusammenführen eine Lösung mit dem tool im Vergleich zu einem 'Allgemeinen Fusion'. Es nicht in den Griff-Projekt-Dateien gedacht.
Projekt: Merge ist mein Werkzeug für das vergleichen und Zusammenführen von XML-Dateien. Ursprünglich schrieb ich es, weil ich erfahren hatte genau dieses problem mit Visual Studio-Projekt-Dateien.
Richtig erkennt neu geordneten Elemente und/oder Attribute innerhalb der XML-Datei und wird korrekt auflösen, fast alle "Konflikte" automatisch.
Möchten Sie vielleicht zu prüfen, verknüpfen Sie Ihr Gerät mit einem trigger in Ihrem SCM (wie ein re-commit-hook für SVN), um die Durchsetzung der neu-Bestellung innerhalb dieser Dateien.
Dann würden Sie eine chance zur effizienten Zusammenführung dieser Elemente zusammen.
Ich in der Regel versuchen zu vermeiden, dass automatisch generierte Dateien im SCM. Automatisch generierte Dateien erzeugt werden sollen, von Quelldateien, die einem Entwickler kontrolliert, und diese kann man unter SCM. Wenn ein bestimmtes tool speichert die Daten in einem undurchsichtigen und zerbrechlich-format, das ist das tool das problem.
Bezug auf Visual Studio, obwohl ich denke, es hat anständige Compiler, Bibliotheken, und eine debugging-Umgebung, glaube ich, dass die Dateien erzeugt (PRJ, SLN, RC) sind höchst problematisch. Abgesehen von den Problemen, die Sie erwähnen, Sie ändern sich auch sehr viel zwischen den verschiedenen VS-Versionen. Aus diesem Grund schreiben wir unsere eigene makefiles, und erstellen Sie die Programme, extern, mit zu machen. Darüber hinaus teilen wir die Ressource-Dateien in Teile, bei denen wir gezwungen sind darauf zu verlassen, VS, und diejenigen, die wir können, sanely-Griff mit einem normalen editor. Wir generieren viele Ressource-Dateien, die automatisch von high-level-Beschreibung, geschrieben in einer benutzerdefinierten domain-spezifische Sprachen. Wir minimieren somit die Auswirkungen von Veränderungen, die schwierig zu handhaben ist unter SCM.
Was wir tun, mit Ressource-Dateien (nicht so viel ärger mit Projekt-Dateien) ist zu Sortieren diese vor der Verschmelzung. Wir so konfiguriert haben, dass der merge-Befehl auf Kunststoff laufen eigentlich eine Art (eine andere app, die wir entwickelt haben, können wir teilen den Verhaltenskodex, wenn Sie interessiert sind, nichts ausgefallenes) vor der Verschmelzung, so dass all die zufälligen Umzüge Weg... Hoffe es hilft.
Überprüfen Sie die installation Optionen - stellen Sie sicher, dass alle Ihre Kollegen haben die x64-compiler-Komponente installiert(oder noch nicht)
Ich geschrieben habe ein kleines Perl-Skript zum Zusammenführen von Dateien mit der Lösung:
http://blog.tedd.no/index.php/2011/01/06/merging-multiple-visual-studio-solution-sln-files-into-one/
Das Skript kann geändert werden, um Ihre Bedürfnisse anzupassen.
Gibt es eine google-Projekt mit dem Namen gyp, erzeugt Visual Studio solutions und Projekte viel wie CMake. Teil des Projekts sind die python tools zum Sortieren von xml-Knoten und-Attribute .sln und .vcproj Dateien jeweils: pretty_sln und pretty_vcproj. Sie herunterladen können, unabhängig von http://gyp.googlecode.com/svn/trunk/tools/
Ich nur angeschaut pretty_vcproj so weit, dehnt es sich auch aus .vsprop Dateien importiert, in der vcproj, wohl zu vergleichen den genauen Inhalt der beiden vcprojs. Die daraus resultierende vcproj entspricht nicht dem schema von Microsoft zwar nicht, aber es würde wahrscheinlich funktionieren, oder könnte man ändern, es ist nur die Art der "Konfiguration" und "Plattform" - Knoten, so dass alles andere intakt. Nicht sicher, ob es die Mühe Wert ist, als es scheinen auch andere Projekte gerichtet, auf die Normalisierung vcprojs schon...