SVN: Die beste Möglichkeit, gemeinsamen Code projektübergreifend zu verwenden

8

Ich habe mehrere Website-Projekte in einem einzigen Repository, von denen jede eine WordPress-Kopie hat. WordPress zu aktualisieren bedeutet, alle Projektordner zu aktualisieren und redundante Kopien zu behalten. Dies ist nützlich für meine rsync-Skripte, die den gesamten Ordner synchronisieren. Es gibt mir auch voll funktionsfähige lokale Kopien der Website.

Es gibt eine Reihe von Möglichkeiten, dies zu verbessern, und ich möchte etwas Feedback dazu bekommen. Ich bin auf Windows und vor kurzem zu Subversion migriert.

  1. Erstellen Sie symbolische Links zu den WordPress-Bits in jedem Website-Ordner. Wird das in Subversion und Apache halten? Irgendwelche Nachteile?
  2. Habe einen einzelnen WordPress-Ordner und verzweige ihn in die anderen Website-Trunks. Ich habe gelesen, dass Filialen billig sind und eine einzelne Kopie erhalten bleibt, aber ich bin mir nicht sicher, ob die Verzweigung über die Stämme hinweg erfolgen sollte. Persönlich denke ich, das ist der beste Ansatz. Gibt es einen Grund, dies zu vermeiden?
  3. Zum Schluss könnte ich die aktuelle Struktur beibehalten und ein Skript verwenden, um Kopien über alle Website-Ordner zu erstellen.

Was ist der beste Ansatz und gibt es alternative Lösungen?

    
aleemb 21.03.2009, 17:38
quelle

8 Antworten

16

Eine Option wäre, die WordPress-Bits in ein separates Repository zu trennen (da es nicht wirklich Teil Ihrer Projekte ist, sondern nur etwas, das Sie zum Erstellen verwenden) und dann svn: externals verwenden, um es in Ihre Projekte zu übernehmen die richtigen Orte.

Externe Definitionen im SVN-Buch

    
Epcylon 21.03.2009, 17:45
quelle
7

Wenn Sie bereits alle Websites zusammen in einem Repository hosten, können Sie mithilfe von svn: externals verschiedene Teile desselben Repositorys auf verschiedene Arten zusammenführen.

z. mit einem Repository wie

%Vor%

Sie können eine Eigenschaft "svn: externals" in den Verzeichnissen site1 und site2 einführen, die "commonPieces url-to-repo / commonPieces" heißt.

Sie sollten hier offensichtlich Rekursionsschleifen vermeiden. Aber das hat den Vorteil, dass sich alles im selben Repository befindet und einen Verlauf teilen kann - Sie können Dinge, die von Site1 oder Site2 immer gebräuchlicher werden, mit "svn copy" in commonPieces ziehen.

Vergleichen Sie unsere aktuelle Lösung, in der ich arbeite - die Migration von Daten aus unseren separaten Projekt-Repositorys in ein einzelnes separates "coreLibraries" -Repository verliert den Entwicklungsverlauf. Da wir häufig Features für ein Projekt entwickeln und dann entscheiden, sie wieder zu verwenden, passiert dieser Verlust der Geschichte viel ...

Edit: Es ist daran zu erinnern, dass "svn update" auf site1 automatisch commonPieces mit dieser "svn: externals" -Eigenschaft aktualisiert, ein "svn commit" auf site1 zeigt jedoch nicht, was sich in site1 / commonPieces geändert hat. Sie müssen zwei separate Commits machen, einen von Site1 und einen von Site1 / CommonPieces.

    
leander 21.03.2009 17:57
quelle
3

Sie könnten eine svn: externe Definition hinzufügen, die auf verweist href="http://svn.automattic.com/wordpress/tags/2.7.1/"> WordPress-Repository oder erstellen Sie Ihr eigenes "angepasstes WordPress-Repository" mit den von Ihnen verwendeten Plugins und Anpassungen.

>     
CMS 21.03.2009 17:45
quelle
2
___ qstntxt ___

Ich habe mehrere Website-Projekte in einem einzigen Repository, von denen jede eine WordPress-Kopie hat. WordPress zu aktualisieren bedeutet, alle Projektordner zu aktualisieren und redundante Kopien zu behalten. Dies ist nützlich für meine rsync-Skripte, die den gesamten Ordner synchronisieren. Es gibt mir auch voll funktionsfähige lokale Kopien der Website.

Es gibt eine Reihe von Möglichkeiten, dies zu verbessern, und ich möchte etwas Feedback dazu bekommen. Ich bin auf Windows und vor kurzem zu Subversion migriert.

  1. Erstellen Sie symbolische Links zu den WordPress-Bits in jedem Website-Ordner. Wird das in Subversion und Apache halten? Irgendwelche Nachteile?
  2. Habe einen einzelnen WordPress-Ordner und verzweige ihn in die anderen Website-Trunks. Ich habe gelesen, dass Filialen billig sind und eine einzelne Kopie erhalten bleibt, aber ich bin mir nicht sicher, ob die Verzweigung über die Stämme hinweg erfolgen sollte. Persönlich denke ich, das ist der beste Ansatz. Gibt es einen Grund, dies zu vermeiden?
  3. Zum Schluss könnte ich die aktuelle Struktur beibehalten und ein Skript verwenden, um Kopien über alle Website-Ordner zu erstellen.

Was ist der beste Ansatz und gibt es alternative Lösungen?

    
___ antwort669644 ___

Es passiert oft, dass ich dieselben Klassenbibliotheken für verschiedene Projekte wiederverwende und in meinem Fall bevorzuge ich eine separate - Freezed - Kopie für jedes Projekt. Der einzige Grund ist, dass ich keine Projekte brechen will, an denen ich eine Zeit lang nicht gearbeitet habe, falls eine der Bibliotheken es überholt. Wenn jedoch jedes Projekt Teil einer Art Hauptprojekt ist, an dem Sie ständig arbeiten, ist es anders.

    
___ answer669643 ___

Vielleicht benutze ich Subversion nur falsch, aber unsere Ordnerstruktur sieht folgendermaßen aus

Trunk    - Ader    - Nachrichten    - Super leistungsstarke Anwendung # 1    - Super leistungsstarke Anwendung # 2    - Super leistungsstarke Anwendung # 3

So teilen sich alle Apps die gleichen Core- und Messaging-Komponenten. Der einzige Nachteil ist, dass wenn Leute sich verzweigen, sie alle Anwendungen bekommen, aber das ist mehr ein Ärgernis als alles andere.

    
___ qstnhdr ___ SVN: Die beste Möglichkeit, gemeinsamen Code projektübergreifend zu verwenden ___ answer669646 ___

Ein besserer Weg, dies zu tun, besteht darin, wordpress in einen separaten Zweig Ihres Repositorys zu verschieben. Dann führen Sie für jede Ihrer Websites eine Konfigurationsdatei ein, die den Pfad zu Wordpress speichert. Sie können diesen Ort an Ihren PHP-Include-Pfad anhängen. Hier ist ein Diagramm:

%Vor%

Das hat einige Vorteile:

  • Sie können mit mehreren Versionen von Wordpress gleichzeitig experimentieren, testen und was nicht. Sie können diese zwischen allen Websites teilen
  • Sie müssen sich keine Sorgen machen, wo Wordpress sich befindet. Das Einbinden einer Bibliothek in ein Projekt ist oft unordentlich, aber diese Art der Einrichtung macht es einfacher, Dinge an einem gemeinsamen Ort zu platzieren.
  • Sie müssen nicht mehrere Versionen der Bibliothek verwalten, das Aktualisieren ist viel einfacher.
___ answer669653 ___

Traditionell sollte alles auf SVN getrennt sein. Es klingt wie Sie SVN als ein Mittel verwenden, um Code aus verschiedenen Bereichen zu greifen und sie zusammenzufügen.

Sie verwenden also SVN als Build-Tool. Es ist besser zu:

  • halte deine Plugins getrennt
  • speichert WordPress selbst nicht in SVN, es sei denn, Sie verwenden einen Lieferantenzweig
  • Wenn Sie eine bestimmte App mit bestimmten Komponenten greifen müssen, arbeiten Sie mit einem Build-Skript.
___ answer669665 ___

Wenn Sie bereits alle Websites zusammen in einem Repository hosten, können Sie mithilfe von svn: externals verschiedene Teile desselben Repositorys auf verschiedene Arten zusammenführen.

z. mit einem Repository wie

%Vor%

Sie können eine Eigenschaft "svn: externals" in den Verzeichnissen site1 und site2 einführen, die "commonPieces url-to-repo / commonPieces" heißt.

Sie sollten hier offensichtlich Rekursionsschleifen vermeiden. Aber das hat den Vorteil, dass sich alles im selben Repository befindet und einen Verlauf teilen kann - Sie können Dinge, die von Site1 oder Site2 immer gebräuchlicher werden, mit "svn copy" in commonPieces ziehen.

Vergleichen Sie unsere aktuelle Lösung, in der ich arbeite - die Migration von Daten aus unseren separaten Projekt-Repositorys in ein einzelnes separates "coreLibraries" -Repository verliert den Entwicklungsverlauf. Da wir häufig Features für ein Projekt entwickeln und dann entscheiden, sie wieder zu verwenden, passiert dieser Verlust der Geschichte viel ...

Edit: Es ist daran zu erinnern, dass "svn update" auf site1 automatisch commonPieces mit dieser "svn: externals" -Eigenschaft aktualisiert, ein "svn commit" auf site1 zeigt jedoch nicht, was sich in site1 / commonPieces geändert hat. Sie müssen zwei separate Commits machen, einen von Site1 und einen von Site1 / CommonPieces.

    
___ answer669674 ___
  

Was ist der beste Ansatz und gibt es alternative Lösungen?

Nicht zum Thema, aber ich schlage vor, dass Sie sich git genauer ansehen. Wir machen das so etwas Tag für Tag mit Submodulen, und es ist ein Kinderspiel.

    

___ tag123branch ___ Ein "Zweig" ist ein Begriff, der in Versionskontrollsystemen verwendet wird, um eine unabhängige Entwicklungslinie darzustellen. Je nach System kann ein Repository einen oder mehrere Zweige enthalten. Verzweigungen werden zusammengeführt, wenn Änderungen von einem Zweig in einen anderen verzweigen müssen. ___ tag123repository ___ Kann sich auf den Datenspeicher eines Versionskontrollsystems beziehen, das den gesamten Verlauf eines Projekts enthält, oder auf ein Objekt, das Daten zwischen der Business-Schicht einer Anwendung und ihrem Datenspeicher überträgt. ___ tag123svn ___ Verwenden Sie dieses Tag für Fragen zu SVN (Subversion), einem zentralisierten Open-Source-Versionskontrollsystem, das unter der Apache-Lizenz vertrieben wird. ___ answer669638 ___

Eine Option wäre, die WordPress-Bits in ein separates Repository zu trennen (da es nicht wirklich Teil Ihrer Projekte ist, sondern nur etwas, das Sie zum Erstellen verwenden) und dann svn: externals verwenden, um es in Ihre Projekte zu übernehmen die richtigen Orte.

Externe Definitionen im SVN-Buch

    
___ answer669642 ___

Sie könnten eine svn: externe Definition hinzufügen, die auf verweist href="http://svn.automattic.com/wordpress/tags/2.7.1/"> WordPress-Repository oder erstellen Sie Ihr eigenes "angepasstes WordPress-Repository" mit den von Ihnen verwendeten Plugins und Anpassungen.

>     
___
Theo.T 21.03.2009 17:47
quelle
1

Vielleicht benutze ich Subversion nur falsch, aber unsere Ordnerstruktur sieht folgendermaßen aus

Trunk    - Ader    - Nachrichten    - Super leistungsstarke Anwendung # 1    - Super leistungsstarke Anwendung # 2    - Super leistungsstarke Anwendung # 3

So teilen sich alle Apps die gleichen Core- und Messaging-Komponenten. Der einzige Nachteil ist, dass wenn Leute sich verzweigen, sie alle Anwendungen bekommen, aber das ist mehr ein Ärgernis als alles andere.

    
Jonathan Beerhalter 21.03.2009 17:46
quelle
1

Ein besserer Weg, dies zu tun, besteht darin, wordpress in einen separaten Zweig Ihres Repositorys zu verschieben. Dann führen Sie für jede Ihrer Websites eine Konfigurationsdatei ein, die den Pfad zu Wordpress speichert. Sie können diesen Ort an Ihren PHP-Include-Pfad anhängen. Hier ist ein Diagramm:

%Vor%

Das hat einige Vorteile:

  • Sie können mit mehreren Versionen von Wordpress gleichzeitig experimentieren, testen und was nicht. Sie können diese zwischen allen Websites teilen
  • Sie müssen sich keine Sorgen machen, wo Wordpress sich befindet. Das Einbinden einer Bibliothek in ein Projekt ist oft unordentlich, aber diese Art der Einrichtung macht es einfacher, Dinge an einem gemeinsamen Ort zu platzieren.
  • Sie müssen nicht mehrere Versionen der Bibliothek verwalten, das Aktualisieren ist viel einfacher.
Dana the Sane 21.03.2009 17:49
quelle
0

Traditionell sollte alles auf SVN getrennt sein. Es klingt wie Sie SVN als ein Mittel verwenden, um Code aus verschiedenen Bereichen zu greifen und sie zusammenzufügen.

Sie verwenden also SVN als Build-Tool. Es ist besser zu:

  • halte deine Plugins getrennt
  • speichert WordPress selbst nicht in SVN, es sei denn, Sie verwenden einen Lieferantenzweig
  • Wenn Sie eine bestimmte App mit bestimmten Komponenten greifen müssen, arbeiten Sie mit einem Build-Skript.
Evert 21.03.2009 17:51
quelle
0
  

Was ist der beste Ansatz und gibt es alternative Lösungen?

Nicht zum Thema, aber ich schlage vor, dass Sie sich git genauer ansehen. Wir machen das so etwas Tag für Tag mit Submodulen, und es ist ein Kinderspiel.

    

gahooa 21.03.2009 18:00
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Paket-Sniffing in Python (Windows)