Empêche le code instable d'entrer dans la ligne par défaut

Question

Actuellement, j'ai 2 référentiel. Un référentiel est nommé jstock, qui contient tout le code source stable.

Un autre référentiel nommé jstock-refactor-calendar-to-joda, qui est cloné à partir de jstock, et il contient tout le code de fonctionnalité expérimentale instable.

Tout le changement-ensemble dans le rectangle rouge est le code de dispositif expérimental instable. Ils ne sont pas encore finis. Par conséquent, je n'ai pas l'intention de le faire fusionner avec l'ensemble de changements dans le rectangle vert (rectangle vert indique que les changements sont stables)

Après jstock-refactor-calendar-to-joda tire à partir de jstock, voici à quoi ça ressemble.

Maintenant, je voudrais laisser le code expérimental visible jstock (mais pas d'entrer dans la ligne par défaut, car ils sont instables)

Par conséquent, lorsque je joue pousser jstock-refactor-calendar-to-joda-jstock, voici ce que Je reçois.

Maintenant tout le code instable appartient à la ligne par défaut!

Ce n'est pas ce que je veux. Dans jstock, je souhaite que le code stable (en rectangle vert) reste en défaut (côté gauche), le code instable (en rectangle rouge) reste dans le côté droit. Notez que je ne veux pas qu'ils soient fusionnés pour le moment, mais j'aimerais que les deux lignes de développement (stable et instable) soient visibles.

Y a-t-il eu une erreur dans ma démarche?

Answer 1

Dans ce cas, vous devez appuyer sur "force" lorsque vous avez créé plusieurs têtes. Les deux ces têtes sont sur la branche "par défaut". Pas de problème avec cela en tant que tel, mais le problème que vous vous inquiétez est que votre nouvelle tête (avec un code instable) est la "pointe" de la branche par défaut.

De l'Mercurial FAQ:

La pointe est toujours une tête.S'il y a têtes multiples dans un dépôt, seulement l'un d'entre eux est le pourboire. Dans un référentiel , les ensembles de modifications sont numérotés de façon séquentielle ( ), ce qui signifie que le numéro de séquence le plus élevé est . Le mot "tip" fonctionne comme une étiquette spéciale à dénote le changeset pointe, et il peut être utilisé partout où un ID de modification est valide.

Il aurait été préférable d'avoir poussé ces changements à une branche nommée, as Lasse suggests, mais vous êtes où vous êtes. Dans ce cas, vous (ou toute personne tirant ce référentiel pour la première fois) devez mettre à jour la copie de travail pour être sur la partie stable de votre branche par défaut.

hg update -r 12345 

(où est le numéro 12345 de révision « Au lieu de limiter la monnaie ... »

Pour les développeurs qui ont déjà ce dépôt, quand ils tirent vos changements instables, ils verront les têtes multiples mais leur copie de travail ne sera pas automatiquement mis à jour à votre nouvelle branche

Answer 2

Dans ce cas, vous auriez probablement dû attendre en poussant, et rendre le référentiel complet disponible.

Ou, lorsque vous avez démarré cette branche, vous devriez lui avoir donné un nom. Vous pouvez avoir plusieurs branches sans nom appartenant toutes à la même branche nommée. En d'autres termes, tous les changements que vous voyez là font partie de la branche default, cependant l'étiquette n'est affichée que pour l'extrémité de cette branche. Depuis les nouveaux changesets sont maintenant la pointe, c'est là que l'étiquette est affichée dans l'interface utilisateur.

Si vous lui aviez donné un nom, la valeur par défaut aurait toujours été désactivée sur votre ensemble de modifications le plus bas sur la branche par défaut.

Pour résoudre ce problème, vous devez "relire" ces modifications un par un. Je ne connais pas la meilleure façon de faire cela, mais il suffit de dire qu'ils obtiendraient de nouveaux hachages, donc quiconque a déjà sorti ces changesets risque de les repousser dans le cadre de la branche par défaut.

Answer 3

Cela a également été affiché sur le Mercurial et au-dessous est mailinglist my reply.

l'emplacement des deux branches (anonymes) dans le journal vi L'aiguière n'est pas importante: il n'y a pas de côté gauche ou droit, l'ordre ne dépend que de l'ordre dans lequel vous avez fait la traction et la poussée.

Ce dont vous avez besoin est un moyen de étiqueter les changesets des branches stable et instable afin que vous puissiez garder une trace de qui est qui. Il y a trois principales façons de le faire:

• clones distincts: C'est la façon triviale que vous avez déjà utilisé où vous gardez un clone séparé pour les différentes branches.

  L'avantage est que vous pouvez facilement supprimer les modifications en supprimant simplement le clone. L'inconvénient est que vous n'avez pas vraiment une vue d'ensemble complète de ce qui se passe puisque les changesets sont conservés isolés.

• branches nommées: voir mon guide ici si vous n'avez pas encore fait:

  http://mercurial.aragost.com/kick-start/en/tasks/

  L'avantage des succursales qui est qu'ils ont mis une étiquette en chaque changeset de telle sorte que vous pouvez suivre d'où ils viennent. Si vous avez une branche nommée appelée « refactoring-calendrier-à-Joda », vous pouvez le faire

  hg update refactor-calendar-to-joda 
  

  afin de mettre à jour la copie de travail à la pointe de cette branche. Lorsque de nouvelles validations sont effectuées sur la branche, la pointe de la branche se déplace et vous pouvez donc considérer 'refactor-calendar-to-joda' comme une balise flottante.

  Pour revenir à la branche par défaut, vous exécutez

  hg update default 
  

  C'est là que le développement normal doit avoir lieu.

  Les branches nommées sont bonnes pour les branches qui sont stables sur une période plus longue ou lorsque le nom a également du sens des années plus tard. Par exemple, si vous utilisez un outil de suivi des bogues, alors je suggère de créer un bogue pour suivre le refactoring et ensuite appeler la branche 'bogue XX'. De cette façon, les utilisateurs peuvent rechercher le bon numéro de bogue dans le futur.

• signets: signets donnent des noms à changesets et comme avec des branches nommées, vous pouvez mettre à jour un signet:

  hg update refactor-calendar-to-joda 
  

  Cependant, contrairement à branches nommées, les signets vivent en dehors du graphique changeset. Parce qu'ils ne font pas partie des changesets eux-mêmes, les signets peuvent être déplacés, supprimés, renommés, etc. Vous pouvez pousser et tirer des signets entre les dépôts.

Il faut donc utiliser des branches nommées pour les noms persistants à long terme, l'utilisation des signets pour les branches de courte durée, et utiliser des référentiels séparés si vous avez des choses séparées.

Enfin, voir ce guide pour en savoir plus sur ce sujet:

http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

Answer 4

Ce que vous avez fait est très bien. Vous avez deux têtes sur la même branche nommée 'par défaut'. C'est une façon tout à fait normale de travailler. Voici une description assez décente de ce qui se passe:

http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/#branching-anonymously

Comme Nick suggère, les gens qui ont déjà un clone obtiendra la nouvelle tête quand ils tirent et les gens qui nouvellement clone auront à la fois - et qui est très bien .

Quand les gens hg update default ou tout simplement hg update ils se sont déplacés vers la nouvelle changeset sur la branche default, donc juste faire une plus engager avec le « Au lieu de limiter décimales de la monnaie ... » changeset comme parent comme celui-ci:

hg update REVSION 
...edit 
hg commit 

Et ils seront automatiquement mis à jour à la branche anonyme que vous voulez quand ils clone/mise à jour. La chose à garder à l'esprit est que mercurial a existé pendant longtemps avant qu'il ait nommé des branches, donc tout ce que vous pouvez faire avec des branches nommées, vous pouvez le faire avec des branches anonymes.

Si vous décidez d'avoir deux têtes indifférenciées dans ce repo est trop déroutant envisager de donner un regard sur les signets. Ce sont des étiquettes collantes qui suivent les conseils des branches anonymes - plus flexibles que les branches nommées car elles ne sont pas permanentes.

http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/#branching-with-bookmarks