Visual Studio, svn und Zusammenführen von .csproj und .sln-Dateien

7

Jeder hatte Erfolg damit, SVN dazu zu bringen, Visual Studio-Projektdateien (.csproj) oder Lösungsdateien (.sln), die von zwei Benutzern bearbeitet wurden, zusammenzuführen? Beispiel

  1. Benutzer A checkt das Projekt aus
  2. Benutzer B checkt dasselbe Projekt aus
  3. Benutzer A fügt eine Datei
  4. hinzu
  5. Benutzer A bestätigt Änderungen
  6. Benutzer B fügt eine Datei
  7. hinzu
  8. Benutzer B bestätigt Änderungen

Es scheint mir, dass in Schritt (6) svn, Tortoise, Ankh oder was auch immer einen Konflikt entdecken sollte und entweder die beiden Projektdateien automatisch zusammenführt oder, wahrscheinlicher, Benutzer B auffordert, den Konflikt zu lösen. Momentan sehen wir Änderungen, die von Benutzer A ausgelöscht werden, wenn Benutzer B eincheckt, was zu fehlerhaften Builds, Deployten usw. führt, die vor dem letzten Einchecken fehlende Features hinzugefügt haben.

Da die Projektdateien XML sind, warum ist das ein Problem? Fehle ich hier etwas? Ich habe die Archive hier durchsucht und gegoogelt, dass ich nicht mehr googlen kann, aber ich habe keine gute Lösung gefunden.

    
David Lively 25.08.2009, 16:42
quelle

5 Antworten

32

Wie glauben Sie, dass Sie SVN dazu gebracht haben, Schritt # 6 auszuführen? Es scheint, dass Sie falsch verstanden haben, was schief läuft. SVN wird niemals von einer nicht aktuellen Arbeitskopie ausgehen , sodass Schritt 6 nicht funktioniert, ohne dass Benutzer B zuvor die Änderungen von Benutzer A aktualisiert und zusammengeführt hat. Ehrlich. Versuch es.

Ich denke, was passiert stattdessen ist das:

  1. Ein Check-out-Projekt.
  2. B checkt dasselbe Projekt aus.
  3. A fügt eine Datei hinzu.
  4. A legt Änderungen fest.
  5. B fügt eine Datei hinzu, vergisst jedoch, das Projekt / die Lösung zu speichern.
  6. B versucht, Änderungen zu übernehmen und erhält eine Nachricht, die er zuerst aktualisieren sollte.
  7. B Aktualisierungen.
  8. B schaltet zurück auf VS. VS sagt ihm, dass das Projekt / die Lösung auf der Festplatte geändert wurde und fragt, ob er a) von der Festplatte neu laden und seine Änderungen verlieren möchte b) die Version auf der Festplatte überschreiben soll.
  9. B versteht nicht, versucht nicht zu verstehen, betrachtet seine Änderungen als wertvoll und wählt b) aus, um die Änderungen auf der Festplatte zu überschreiben.
  10. B versucht immer noch nicht zu verstehen und unterscheidet daher nicht die Version, die er auf der Platte mit der letzten festgeschriebenen Version hat, und vermisst so, dass er A's Änderungen außer Kraft setzt.
  11. B Überprüft die Änderungen von A.

Ich habe das hin und wieder gesehen, normalerweise mit einem Benutzer B, der den Workflow von SVN (oder CVS, FTM) nicht wirklich versteht.

Also hier ein paar Tipps:

Aktualisieren Sie nicht, es sei denn, Sie haben alles gespeichert ("Datei" - "Alles speichern"; für mich ist das Strg + Umschalt + S). Falls Sie diesen Fehler gemacht haben und festgefahren sind, überschreiben Sie die Änderungen auf der Festplatte und fügen Sie die verlorenen Änderungen manuell zusammen . (Es könnte auch funktionieren, die Projekt- / Lösungsdatei wieder auf Version N-1 und dann wieder auf HEAD zu aktualisieren, damit SVN die Zusammenführung durchführen kann.)

Begehen Sie nicht, ohne zu prüfen, welche Dateien Sie geändert haben und Sie haben einen schnellen Blick auf die Diffs Sehen Sie, ob die Änderungen das sind, was Sie erwarten.

Frühzeitig committen, häufig committen . Je mehr Entwickler an derselben Codebasis arbeiten, desto wahrscheinlicher sind Konflikte. Je länger Sie Ihre Arbeitskopie ohne Aktualisierung ändern, desto wahrscheinlicher sind Konflikte. Da die Anzahl der Entwickler normalerweise nicht in Reichweite ist, ist die Aktualisierungshäufigkeit die einzige Möglichkeit, mit der Sie die Wahrscheinlichkeit von Konflikten reduzieren können.

    
sbi 25.08.2009, 17:15
quelle
2

Ich zweite sbi's Antwort. Eine mögliche Lösung besteht darin, immer innerhalb von Visual Studio zu aktualisieren, zumindest wenn Sie VisualSVN verwenden (ich bin nicht sicher, wie AnkhSVN diese Situation bewältigt).

VisualSVN blockiert Visual Studio während des Aktualisierungsvorgangs und stellt sicher, dass alle geänderten Projekte automatisch neu geladen werden, sodass Benutzer die externen Änderungen nicht ignorieren können.

    
jeroenh 26.08.2009 12:03
quelle
1

Eine eher radikale, aber effiziente Lösung besteht darin, ein Werkzeug zu verwenden, um diese Lösungsdateien aus einer Metadefinition zu generieren und dann nur die Metadefinition unter die Quellcodeverwaltung zu stellen, nicht Visual Studio-Projektdateien (was ein Albtraum ist).

In meinem Team verwenden wir MPC , um dies zu tun. Wir haben:

  • eine Menge .mpc-Dateien für Projektbeschreibungen,
  • eine .mwc-Datei für die Beschreibung des Arbeitsbereichs / der Lösung,
  • eine kleine .cmd, um Visual Studio-Dateien zu generieren.

Da es sich um handbearbeitete Textdateien handelt, haben wir keine Probleme damit, dass Visual Studio alles vermischte.

Die Nachteile sind ein Extra-Tool und die Notwendigkeit, die Lösungsdateien neu zu erstellen, wenn Dateien hinzugefügt oder entfernt werden, aber es gibt auch einige zusätzliche Vorteile:

  • Projektkonfigurationen sind zentralisiert: Beispielsweise wird das Ändern eines Kompilierungs-Flags an einer einzigen Stelle statt auf einer pro-Projekt-Basis durchgeführt,
  • Dies kann mehrere Build-Systeme aufnehmen (wir verwenden derzeit Visual 2003 und 2005, aber dies funktioniert auch mit gcc und anderen).

Aus meiner Erfahrung kann die Einrichtung des Tools zwar etwas schmerzhaft sein (aber alles hängt von der Größe und Komplexität Ihres Projekts ab), das ist es definitiv wert.

Beachten Sie, dass MPC nicht das einzige Werkzeug für diesen Zweck ist. Andere existieren, wie CMake .

    
Stéphane Bonniez 25.08.2009 17:22
quelle
1

Sie können auch versuchen, Konflikte zu reduzieren, indem Sie sicherstellen, dass Ihre Projektdateien nicht jede einzelne Datei im Projekt auflisten. Dadurch wird vermieden, dass die Projektdatei an erster Stelle geändert wird, wenn ein Benutzer eine Datei hinzufügt.

Sie können in einer Projektdatei Platzhalter verwenden: siehe MSDN

Beispiel:

%Vor%

Es ist traurig, dass Visual Studio diese Art der Projekteinrichtung nicht unterstützt und stattdessen einzelne Dateien auflistet.

    
Stefan Sieber 03.01.2014 10:16
quelle
0

Das ist sehr langwierig und ermüdend, also musst du es nur durchpflügen. Sie behalten manchmal die lokale Arbeitskopie, da alle Ihre benutzerdefinierten Projekte hinzugefügt wurden. In anderen Fällen möchten Sie jedoch alle neuen Elemente aus der Basislösung zusammenführen, sodass Sie alles aus beiden Lösungsdateien erhalten. Aus Gründen der Lesbarkeit ist es am besten, alle Grundprodukt-Ergänzungen vor den Anpassungen hinzuzufügen.

Mach dir keine Sorgen, dass der erste Teil der GUID für Projekte identisch ist, aber es ist der letzte Teil, der eindeutig sein wird.

Fissh

    
gadildafissh 18.05.2015 23:58
quelle

Tags und Links