Wie schaffen Sie es VCPROJ Dateien in der Quellcodeverwaltung, die von mehreren Entwicklern geändert werden?

StackOverflow https://stackoverflow.com/questions/166796

  •  03-07-2019
  •  | 
  •  

Frage

Wir verwenden Subversion als unser Quellcodeverwaltungssystem und speichern Sie die Visual Studio-Projektdateien (vcproj) in dem Quellensteuersystem, wie normal, denke ich. Mit Subversion wir keine Form von Dateisperren verwenden also, wenn zwei Entwickler am gleichen Projekt zur gleichen Zeit arbeiten und beide fügen Sie Dateien in das Projekt, oder Einstellungen ändern, die zweite zu begehen hat, um die Änderungen zu verschmelzen.

Wie fusionieren Sie diese Änderungen?

Die vcproj Dateien sind nur Textdateien, so dass es möglich ist, sie von Hand zu bearbeiten, aber sie sind nicht sehr zugänglich Hand Bearbeitung, insbesondere durch Junior-Entwickler.

Die Möglichkeiten, wie ich denken kann, sind

  • Laden Sie die neueste Version aus dem SVN und erneut hinzufügen alle lokalen Änderungen manuell
  • Bearbeiten Sie die Datei von Hand alle Konflikte aus einer automatischen Zusammenführung zu lösen
  • Implementieren Sie irgendeine Form Schema Sperren gleichzeitige Änderungen zu verhindern
  • eine Vereinbarung zwischen den Entwicklern haben, so dass sie nicht gleichzeitig Änderungen vornehmen

Zur Zeit verwenden wir die erste Möglichkeit, erneut hinzufügen alle Änderungen manuell, aber dies ist zeitaufwendig und ich habe mich gefragt, ob es einen besseren Weg gibt.

Mit Quelldateien die automatische Druckfunktion funktioniert die meiste Zeit und wir nicht bekommen, viele Konflikte.

War es hilfreich?

Lösung

Ich habe diese Option 2 (bearbeiten Sie die Dateien von Hand) gefunden im Allgemeinen recht gut, so lange funktioniert, wie Sie ein gutes Diff-Tool verwenden (ich verwende WinMerge ). Das Hauptproblem, ich habe laufen in ist, dass Visual Studio wird manchmal die Datei neu anordnen. Aber, wenn Sie ein gutes Diff / Merge-Tool haben, dann sollten sie in der Lage sein, zwischen geändertenem Inhalt zu unterscheiden und bewegten Inhalt. Das kann viel helfen.

Andere Tipps

Dies ist ein schwieriges Problem und ich denke, eine Schwäche in der Visual Studio-Architektur. Die Art, wie wir fanden Runde war es nicht die Proj-Dateien überhaupt in der Quellcodeverwaltung haben und einen Build-Skript zu haben, der die Konfigurationseinstellungen behandelt.

Die Alternative war sehr chaotisch und wir konnten nicht garantieren konsistente baut oder Umgebungen zwischen Entwicklern. Dies führte zu einer großen Anzahl von nachgelagerten Integrationsproblemen und wir haben schließlich den drakonischen Schritt der Projektdateien aus der Quellcodeverwaltung zu entfernen.

Die Entwickler-Umgebungen könnte noch falsch ausgerichtet werden, aber es zeigte sich, wenn sie versucht, die Dinge selbst zu bauen.

Mit TFS hier, aber ich glaube nicht, es macht einen Unterschied.
Wir sperren auch nicht, und manchmal mit verschmelzenden Projektdateien zu tun haben. Ich habe festgestellt, es nie, dass komplexe oder sehr ein Problem zu sein. Selten erleben wir immer Probleme, die nicht automatisch zusammengeführt werden können, und die manuelle Mergeprozesses ist ziemlich trivial.

Es gibt nur eine Einschränkung dabei: Check-in oft! Wenn Sie größere Änderungen an der Projektstruktur zu machen und sie nicht in sofort überprüfen können diese Änderungen starten die Komplexität der später verschmilzt Compoundierung. Wenn ich eine große Veränderung der Struktur eines Projekts machen, in der Regel gebe ich jeder ein Heads-up. Ich werde sie alle fragen in ihrer aktuellen Arbeit zu überprüfen, und dann der Zusammenführung selbst kümmern.

ich das vor kurzem gefunden: http://www.codeproject.com/KB/macros /vcproj_formatter.aspx Wenn Sie das Tool auf einer vcproj Datei und auf einer modifizierten Version davon laufen, dann können Sie sie einfach zusammen mit Ihrem bevorzugten Text Merge-Tool fusionieren, und zusätzlich ist das Ergebnis eine kompaktere ziemlich vcproj Datei.

Optionen 1 und 2 schließen sich nicht aus - wenn der Entwickler Junior-Ebene ist, lassen Sie sie Option 1 (die Projektdatei erneut bekommen und wieder tun, um die Änderungen), wenn das für sie bequemer ist. Weiteren Senior-Entwickler, Option 2 (merge ein Merge-Tool) ist völlig in Ordnung.

Ich denke, dies ist eine Situation, die derzeit keine magische Kugel hat - manchmal Verschmelzung ist ein Schmerz

.

Wir verwenden ein Diff-Tool ( WinMerge ) Änderungen zu verschmelzen. Die Projektdateien sind (zum größten Teil) wirklich geradlinig XML. Der Schlüssel hier ist allerdings, dass es nie irgendwelche Überraschungen geben beim Zusammenführen, weil eine gute Kommunikation Teil des Bettes-Rock der effektiven Quelle Kontrolle ist.

Gleichzeitige Änderungen in das Projekt sind völlig in Ordnung, so lange wie Menschen miteinander kommunizieren.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top