Beste Strategie zum Verzweigen von SVN-Code und Verwalten von Visual Studio-Projektreferenzen

Question

Wir haben ein Visual Studio-Hauptprojekt in SVN gespeichert, das die Standardstruktur trunk/branches/tags verwendet. Dieses Projekt verweist jedoch auf externe Projekte außerhalb dieser Struktur. Wenn wir also einen Codezweig erstellen, schlagen alle Referenzen auf die exteranl-Projekte fehl, da sie eine Ebene lang sind.

dh. trunk/MyProjectCode wird nach der Verzweigung zu branches/MyFeatureBranch/MyProjectCode, und aufgrund dieser zusätzlichen Hierarchieebene schlagen alle Verweise auf externe Projekte fehl.

Was ist der beste Weg, Zweige mit möglichst wenig Reibung zu erzeugen? Ich könnte ein Skript schreiben, das alle Projektreferenzen ändert, oder ich könnte mein lokales Code-Layout ändern, so dass die Zweige tatsächlich eine Ebene unterhalb des Trunks sind, daher wäre ein neuer Zweig auf derselben Ebene. Irgendwelche anderen Vorschläge/Best Practices?

Answer 1

Beim Auschecken aus Subversion muss Ihr Arbeitsverzeichnis nicht dieselbe Verzeichnistiefe wie im Repository aufweisen. Verwenden der Befehlszeile zum Beispiel Zwecke:

svn co svn://server/project/trunk project 
svn co svn://server/project/branches/MyFeatureBranch project-feature

Auf diese Weise haben Sie zwei Verzeichnisse nebeneinander project und project-feature genannt. Dies sollte Probleme mit unterschiedlichen Verzeichnistiefen und relativen Pfadreferenzen vermeiden.

Answer 2

Wir verzweigen alles, was zu diesem Produkt gehört. Wenn es also 5 Projekte gibt, die Teil davon sind, verzweigen wir alle 5 Projekte, um sicherzustellen, dass wir eine vollständige Kopie davon haben, was diese Filiale benutzen wird. Wenn Sie Probleme mit Pfaden haben, sollten Sie das Programm Junction ausprobieren.

Answer 3

Was ich in der Vergangenheit getan habe, ist für einen Entwicklungsladen, der viele Projekte und viele gemeinsame Referenzen entwickelt, die externen Referenzen an einem gemeinsamen Ort zu halten. Dies kann eine Netzwerkfreigabe sein oder ein vereinbarter (absoluter) Speicherort, den jeder auf seiner Festplatte hat (strukturiert wie C: \ SharedLibs \ Library \ Version). Wir haben die sharedlibs in einem separaten svn-Repository gespeichert, in dem jeder den SharedLibs-Ordner auschecken musste, und unsere Referenzen auf diesen absoluten Pfad eingerichtet.

Eine andere Strategie, die ich angewendet habe, ist, was Sie auch in vielen Open-Source-Projekten finden: Speichern Sie einfach die Referenzen neben Ihrem Projekt. Z.B. Sie könnten einen Stamm mit den Unterordnern src (für Quellcode) und lib (für externe Referenzen) haben. Dies ist wahrscheinlich eine bessere Vorgehensweise: Alles, was Sie tun müssen, um das Projekt zu erstellen (sei es Stamm oder Zweig), ist es auszuprobieren und das Build-Tool auszuführen.

Eine weitere Option verwendet die Eigenschaft svn: externals. Mit dieser Eigenschaft können Sie sicherstellen, dass Dateien von anderen Speicherorten in Ihrem Repository (oder von anderen Repositories) gemeinsam mit Ihrem Projekt ausgecheckt werden. Aus Erfahrung empfehle ich das nicht, aber es ist eine Option. Lesen Sie darüber in der Svn Buch: http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html

Answer 4

Wir hatten das gleiche Problem hier und ich habe über die Bearbeitung der .SLN und .CSproj Dateien ersetzen die relativen Pfade mit absoluten. Ich war ein wenig besorgt darüber, weil VS diese Dateien beibehält und sie davon abhält, dies rückgängig zu machen und zu einem späteren Zeitpunkt wieder auf relative Pfade zurückzusetzen (wenn ein Entwickler das Projekt speichert und zum Beispiel eincheckt).

Heute morgen hatte ich einen "Moment der Klarheit" auf meinem Weg: Obwohl wir die Filiale in einem dedizierten Filialordner ablegen, warum muss ich sie dann in einem Ordner auschecken?

so statt:

C: 
|_ svnworkarea 
     |_ project 
      |_ branches 
       |_ project-feature 
         |_ source etc 

      |_ trunk 
       |_ source etc 

Ich habe jetzt:

C: 
|_ svnworkarea 
    |_ project 
     |_ project-feature 
       |_ source etc 

     |_ trunk 
       |_ source etc 

Da die Quellordner nun auf dem gleichen Niveau sind die relativen Pfade gültig sind und die Referenzen zu laden, wie erwartet. Der Stamm ist immer noch vollständig getrennt und leicht zu identifizieren, während die Projektmerkmale durch einen aussagekräftigen Ordnernamen identifiziert werden, z. NewUIBranch.