Utilisation de Mercurial pour séparer les versions privée et publique

Question

Comment utiliseriez-vous Mercurial pour résoudre le problème suivant?

Supposons que j'ai une bibliothèque Core. Je veux maintenant développer une extension à cette bibliothèque appelée Extension. Je veux que Core soit physiquement séparé de Extension, c’est-à-dire que Core est une bibliothèque open source et Extension est une bibliothèque privée qui s’appuie sur Core (peut-être qu’elle contient des éléments que je souhaite garder personnels. Peu importe.). Évidemment, je ne veux pas jamais transférer toute la source de Extension dans le référentiel public. Mais d’autre part, je souhaiterais peut-être appliquer certaines modifications de Extension à Core (si je décidais de "donner" une partie de l’extension au Core) ou inversement (si je souhaitais intégrer des corrections de bugs, par exemple).

Comment vous y prendrez-vous, tout en minimisant le risque de fuite de Extension à Core (une fois que l'historique est transmis au serveur public, vous ne pouvez plus revenir en arrière!), tout en restant flexible pour effectuer certains changements. Branches? Des clones? Mqs? Autre chose?

Je ne connais pour l'instant que les référentiels de clonage, et j'aime beaucoup sa simplicité.

MODIFIER: Je suis venu avec ce schéma, mais je ne peux pas vraiment le faire fonctionner sous Windows. Deux référentiels (Core et Extension). Dans Extension, il y a deux branches , ainsi que Core et extension. Maintenant, vous pouvez enregistrer un hook dans chaque référentiel dans Mercurial. Je souhaiterais donc enregistrer un hook 'pretxnchangegroup' dans le référentiel Core qui interdit les archivages de la branche Extension, comme expliqué dans le livre Mercurial . Sauf que je ne comprends pas trop que cela fonctionne sous Windows. Donc:

• Quelqu'un a-t-il un exemple de ce type (en fait, un crochet qui modifie le résultat d'une transaction) sous Windows?
• Je pourrais toujours utiliser la transplantation pour modifier les changements de cherrypick de l'extension à la branche principale, n'est-ce pas?

Answer 1

Après quelques essais, je vais essayer ce schéma. Deux référentiels principaux et deux branches nommées, Core et Extension.

Un référentiel principal principal, qui ne devrait contenir que les ensembles de modifications principaux et la source. Il ne doit donc contenir que des jeux de modifications de la branche Core. Ceci est vérifié en utilisant le hook de référentiel suivant dans hgrc de ce référentiel:

pretxnchangegroup.branch = hg head --template " branches actuelles: {branches} " | rechercher " extension " & amp; & amp; sortie 1 || exit 0

Ça a l'air un peu bizarre, mais au fond, ça se déclenche après une poussée ou une traction, mais avant que cela soit commis. À ce stade, si le raccordement échoue, la transaction est annulée. Ainsi, le point d’accès recherche un ensemble de modifications de la branche Extension et échoue s’il le trouve, interdisant ainsi à ses modifications d’entrer dans le référentiel principal.

Le deuxième référentiel contient à la fois des branches et des ensembles de modifications Core et Extension. Il consiste à échanger les ensembles de modifications entre les deux branches. Fusion normale du noyau vers l’extension et transplantation d’extension vers le noyau.

espérons que cela aide quelqu'un d'autre.

Answer 2

  

(une fois que l'histoire est poussée, il y a   pas de retour!)

bien sûr qu'il y a ... c'est ce que le contrôle de version concerne!

Je n'ai jamais rien fait de tel auparavant, mais cela ressemble au La transplantation sera utile. En outre, vous pouvez avoir des clones de clones et les pousser à n’importe lequel d’eux, et cetera.

Answer 3

La extension de forêt vous permet de conserver plusieurs restitutions en tant que partie d'un grand. On dirait que cela pourrait aider ici.