Branche de fournisseur, style mercurial?

Question

La scène: Une application Web achetée, avec des mises à jour régulières du fournisseur. Ensuite, nous personnalisons fortement le look et parfois nous ajoutons nos propres fonctionnalités ou nous corrigeons un bug avant que le vendeur n'y arrive. Pour le contrôle de version, nous avons utilisé Subversion en suivant leur modèle “Vendor Branch” chaque fois que nous avons reçu une nouvelle version. Cela a l'avantage supplémentaire que nous avons une version contrôlée de la copie de leur système.

Le problème: Nous aimerions passer à Mercurial et suivrons probablement le modèle stable/default branching. Mercurial prend tout son sens si nous ne recevions qu'une seule version de notre fournisseur et commençons à la développer à partir de là. Mais, pour une raison quelconque, j'ai de la difficulté à comprendre comment gérer les versions futures du fournisseur.

Le plaidoyer: Toute aide avec "Mercator rami" style Mercurial serait grandement appréciée.

Answer 1

en utilisant des branches nommées comme vous l'avez décrit est un bon choix (si not the only choice), mais je vous suggère encore en utilisant quelques clones séparés à des endroits bien connus de faciliter ce processus. Prétendre que http://host/hg/ est un hgweb (anciennement hgwebdir) pour votre installation (si ssh: // fonctionne très bien aussi, peu importe), vous auriez quelque chose comme ceci:

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

Deux repos séparés où les données passent du fournisseur à la douane mais jamais dans l'autre direction. La branche nommée default serait la seule en vendor et en custom vous auriez à la fois default et stable.

Lorsque vous avez une nouvelle baisse de code du fournisseur que vous souhaitez déballer dans le répertoire de travail du repo vendor, puis exécutez:

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

Votre histoire dans cette prise en pension vendor sera linéaire, et il n'aura jamais rien que tu aies écrit.

maintenant dans votre clone local du custom repo que vous feriez:

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 

Et puis vous faites le travail de la fusion de vos chances locales en cas de défaut avec leur nouvelle chute de code. Lorsque vous êtes satisfait de la fusion (passage des tests, etc.), vous devez repasser de votre clone local à http://host/hg/custom. Ce processus peut être répété si nécessaire, assure une bonne séparation entre votre historique et le leur, et permet à tout le monde dans votre équipe de ne pas accepter de nouvelles demandes de code de la part des fournisseurs, de se préoccuper uniquement d'une configuration normale en une seule opération. repo, http://host/hg/custom.

Answer 2

J'utiliserais une branche fournisseur en tant que branche supplémentaire par défaut + stable. En fin de compte, il ressemblerait à quelque chose comme ceci:

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