Lieferanten Branching, Mercurial Style?

Question

Die Szene: Eine gekaufte Webanwendung, mit regelmäßigen Updates vom Anbieter. Dann passen wir das Aussehen stark an und fügen manchmal unsere eigenen Funktionen hinzu oder beheben einen Fehler, bevor der Hersteller darauf zugreift. Für die Versionskontrolle haben wir Subversion nach ihrem “Vendor Branch” Modell jedes Mal verwendet, wenn wir eine neue Version erhalten haben. Dies hat den zusätzlichen Vorteil, dass wir eine versionskontrollierte Vanilla-Kopie ihres Systems haben.

Das Problem: Wir möchten zu Mercurial wechseln und werden wahrscheinlich dem Muster stable/default branching folgen. Mercurial macht Sinn, wenn wir nur eine einzige Version unseres Anbieters erhalten und von dort aus entwickeln. Aber aus welchen Gründen auch immer, ich habe Probleme damit, zukünftige Versionen des Anbieters zu behandeln.

Das Plädoyer: Jede Hilfe mit "Vendor Branching" Mercurial-Stil würde sehr geschätzt werden.

Answer 1

Mit dem Namen Zweig, wie Sie ist eine gute Wahl beschrieben hast (obwohl not the only choice), aber ich würde noch ein paar getrennten Klone unter Verwendung von gut bekannten Stellen vorschlagen, diesen Prozess erleichtern. So zu tun, dass http://host/hg/ ist ein hgweb (früher hgwebdir) für Ihre installieren (obwohl ssh: // funktioniert zu groß, was auch immer), können Sie so etwas wie dieses haben würde:

• http://host/hg/vendor
• http://host/hg/custom

Zwei separate Repos, bei denen der Datenfluss vom Lieferanten zum Kunden erfolgt, aber niemals in die andere Richtung. Der benannte Zweig default wäre der einzige in vendor und in custom hätten Sie beide default und stable.

Wenn Sie einen neuen Code Drop vom Anbieter bekommen würden Sie es in das Arbeitsverzeichnis des vendor Repo, entpacken und dann laufen:

hg addremove 
hg commit -m 'new drop from vendor, version number x.x.x' 

Ihre Geschichte in dieser vendor Repo wird linear, und Es wird nie etwas haben, was du geschrieben hast.

Jetzt in Ihrem lokalen Klon des custom Repo Sie tun würde:

hg update default  # update to the latest head in your default branch 
hg pull http://host/hg/vendor # bring in the new changes from vendor as a new head 
hg merge tip   # merge _your_ most recent default cset with their new drop 

Und dann tun Sie die Arbeit Ihrer lokalen Chancen auf Standard mit ihrem neuen Code Drop verschmelzen. Wenn Sie mit der Zusammenführung zufrieden sind (Tests usw.), drücken Sie von Ihrem lokalen Klon zurück auf http://host/hg/custom.

Dieser Prozess kann nach Bedarf wiederholt werden, bietet eine gute Trennung zwischen Ihrer Geschichte und deren, und jeder in Ihrem Team nicht verantwortlich für das Akzeptieren neuer Code fällt von Anbietern, sich nur mit einer normalen default/stable Setup in einem einzigen beschäftigen Repo, http://host/hg/custom.

Answer 2

Ich würde einen Lieferantenzweig als eine zusätzliche Verzweigung zu den Standard + stabile verwenden. Am Ende wäre es etwa so aussehen:

V1----V2-------------V3---------V4  Vendor 
\  \    \   \ 
    D1----D2---D3--D4-D5-D6-D7-D8---D9 default 
        \   \ \ 
        S1----------S2---S3 stable