SVN: Beste Weg, um gemeinsamen code zwischen Projekten

Ich habe mehrere website-Projekte in einem einzigen repository von denen jede eine Kopie von WordPress. Die Aktualisierung von WordPress bedeutet, dass die Aktualisierung alle Projekt-Ordner und halten redundante Kopien. Dies ist nützlich für mein rsync-Skripte, die synchronisieren den gesamten Ordner. Es gibt mir auch voll arbeiten lokale Kopien der site.

Gibt es eine Reihe von Möglichkeiten, die ich sehen kann, zu verbessern und würde gerne etwas feedback. Ich bin auf Windows und vor kurzem migriert, um Subversion.

  1. Erstellen Sie symbolische links auf die WordPress-bits in den jeweiligen website-Ordner. Wird diese gedrückt halten, bis in Subversion und Apache. Irgendwelche Nachteile?
  2. Eine einzelne WordPress-Ordner, und verzweigen Sie in andere website trunks. Ich habe gelesen, dass Zweige sind Billig und ein einziges Exemplar ist erhalten, aber ich bin nicht sicher, ob die Verzweigung sollte gemacht über trunks. Ich persönlich glaube, dass dies der beste Ansatz. Gibt es einen Grund, dies zu vermeiden?
  3. Schließlich, ich könnte halten Sie die derzeitige Struktur und ein Skript verwenden, um Kopien für alle website-Ordner.

Was ist der beste Ansatz, und gibt es irgendwelche alternativen Lösungen?

InformationsquelleAutor aleemb | 2009-03-21
  1. 16

    Wäre eine option zu trennen Sie die WordPress-bits in einem separaten repository (da es nicht wirklich ein Teil Ihrer Projekte, es ist einfach etwas, das Sie verwenden, Sie zu bauen), und verwenden Sie anschließend svn:externals zu Holen, die in Ihre Projekte in den richtigen stellen.

    Externals-Definitionen in der SVN-Buch

    InformationsquelleAutor Epcylon
  2. 7

    Wenn Sie bereits hosting alle Seiten zusammen in einem repository svn:externals können verwendet werden, um ziehen verschiedene Teile des gleichen repository zusammen in verschiedener Weise.

    E. g. mit einem repository wie

    repo/site1 
repo/site2 
repo/commonPieces

    Können Sie sich vorstellen ein "svn:externals" - Eigenschaft auf der site1 und site2 dirs, der sagt "commonPieces url-to-repo/commonPieces".

    Werden Sie wollen vermeiden, dass jede Rekursion Schleifen hier offensichtlich. Aber das hat den Vorteil, dass alles in der gleichen repository und teilen können, die Geschichte -- die man ziehen kann, Dinge, die immer häufiger von site1 oder site2 in commonPieces mit "svn copy".

    Vergleichen Sie unsere aktuelle Lösung, wo ich arbeite, -- migrieren von Sachen von unserer separate Projekt-repositories in einem einzigen auch separate "coreLibraries" repository verliert der Entwicklung der Geschichte. Da wir Häufig entwickeln features für ein Projekt und entscheiden Sie dann, wieder verwenden Sie, dieser Verlust der Geschichte passiert eine Menge...

    Edit: es lohnt sich zu erinnern, dass, während "svn update" auf site1 wird automatisch aktualisiert, commonPieces mit diesem "svn:externals" - Eigenschaft, wird ein "svn commit" auf site1 wird nicht angezeigt, die Dinge haben sich geändert in site1/commonPieces. Sie müssen zwei separate verpflichtet, eine von standort1 und eine aus site1/commonPieces.

    InformationsquelleAutor leander
  3. 3

    Könnte man hinzufügen, eine svn:external definition verweist auf die WordPress-repository oder machen Sie Ihre eigenen "customized WordPress-Repository" mit den plugins und Anpassungen, die Sie verwenden.

    • Scheint, wie genau das, was ich brauche. Ist es besser, Punkt für jedes Projekt die WordPress-repo-oder zeigen Sie einen gemeinsamen Ordner aus dem WordPress repo und zeigen Sie dann den anderen Ordner, um die gemeinsamen Ordner? (Kann das auch getan werden, also Kette Sie zusammen, wie, die)
    InformationsquelleAutor CMS
  4. 2

    Oft passiert es mir möglich die gleichen Klassenbibliotheken für unterschiedliche Projekte und in meinem Fall habe ich lieber eine separate - eingefroren - Kopie für jedes Projekt. Der einzige Grund dafür ist, dass ich nicht wollen, zu brechen Projekte, die ich habe nicht für eine Weile gearbeitet, falls einer der Bibliotheken outdates es. Allerdings, wenn jedes Projekt ist ein Teil einer Art von Projekt Sie arbeiten ständig an ist es anders.

    InformationsquelleAutor Theo.T
  5. 1

    Vielleicht bin ich auch nur mit Subversion der falsche Weg, aber unsere Ordner-Struktur sieht wie folgt

    Stamm
    - Kern
    - Messaging
    - Super Leistungsstarke Anwendung #1
    - Super Leistungsstarke Anwendung #2
    - Super Leistungsstarke Anwendung #3

    So dass alle unsere Anwendungen teilen die gleichen Kern-und Messaging-Komponenten. Der einzige Nachteil ist, dass, wenn die Menschen Zweig, bekommen Sie all die Anwendungen, aber das ist mehr ein ärgernis als alles andere.

    • dieser Ansatz klingt nicht richtig. Checking out alle Projekte arbeiten auf ein einzelnes Projekt kann nicht gut sein.
    • Ich habe immer gedacht, die gleiche Sache, die mich eigentlich, also wenn jemand einen besseren Vorschlag, ich bin für hören.
    InformationsquelleAutor Jonathan Beerhalter
  6. 1

    Einen besseren Weg, dies zu tun ist, ziehen Sie wordpress in einem separaten Zweig des Repositorys. Dann bringt eine config Datei, um alle Ihre websites, speichert den Pfad zu WordPress. Sie können den anfügen, diese Position in den php-include-Pfad. Hier ist ein Diagramm:

    Svn repo-v
         |-Websites--v
         |           |---One
         |           |---Two
         |-Wordpress-v
                     |---branch one
                     |---branch two

    Dies hat ein paar Vorteile:

    • Sie können Experimentieren mit unterschiedlichen Versionen von WordPress auf einmal, testen wollen und was nicht. Sie können diese zwischen allen websites
    • Sie sich nicht sorgen, wo wordpress ist check-out um. Darunter eine Bibliothek in einem Projekt ist oft chaotisch, aber diese Art von setup macht es einfacher, Dinge zu setzen, in einigen gemeinsamen Standort.
    • Sie müssen nicht mehrere Versionen der Bibliothek, die Aktualisierung ist viel einfacher.
    InformationsquelleAutor Dana the Sane
  7. 0

    Traditionell alles, was getrennt werden soll, auf SVN. Es klingt wie Sie sind mit SVN als ein Mittel zu greifen, code aus unterschiedlichen Bereichen und Nähen Sie zusammen.

    Also bist du mit SVN als build-tool. Es ist besser, zu :

    • halten Sie Ihre plugins separate
    • speichern nicht wordpress selbst im SVN, es sei denn, Sie verwenden eine vendor branch
    • wenn Sie benötigen, um grab eine bestimmte app mit bestimmten Komponenten, arbeiten mit einem build-Skript.
    InformationsquelleAutor Evert
  8. 0

    Was ist der beste Ansatz, und gibt es irgendwelche alternativen Lösungen?

    Nicht zu gehen off-topic, aber ich schlage vor, Sie nehmen einen harten Blick auf git. Wir tun, diese Art der Sache, die Tag ein, Tag aus mit Submodule, und es ist ein Kinderspiel.

    FYI - Migration von SVN über 2 Jahren durch diese Art von Problemen.

    • Interessant, kann man schnell erklären, was es einfacher macht, mit git in Ihrem Fall ?
    • Ich gebe ihm einen harten Blick. Eine Sorge ist, ob es integriert werden können andere SVN-repositories wie SVN:external tut, das eröffnet eine Welt der Möglichkeiten. Ich mag git für das Versprechen einer Leistung, kleine Stellfläche, Verzweigungen etc
    InformationsquelleAutor gahooa
Schreibe einen Kommentar