Empêcher le code instable va en ligne par défaut

Question

À l'heure actuelle, 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 jstock, et il contient tout le code de fonctionnalité expérimentale instable.

Tous les changement dans le rectangle rouge jeu est un code instable de fonction expérimentale. Ils ne sont pas encore terminés. Par conséquent, je n'ai pas l'intention de le faire fusionner avec le changement ensemble dans le rectangle vert (rectangle vert indique ce sont changement ensemble stable)

Après jstock-refactor-calendar-to-joda tractions 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, quand je joue de pousser jstock-refactor-calendar-to-joda à jstock, voici ce que je reçois.

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

pas ce que je veux. En jstock, je souhaite que le code stable (dans le rectangle vert) reste en défaut (côté gauche), il reste dans le côté droit du code instable (dans le rectangle rouge). Notez que, je ne veux pas qu'ils soient encore fusionnés, mais je voudrais avoir les deux lignes de développement (stables et instables) étant visibles.

Y at-il pas que j'avais mal fait?

Answer 1

Dans ce cas, vous devez avoir la « force » poussée que vous avez créé plusieurs têtes. Les deux ces têtes sont sur la branche « par défaut ». Pas de problème avec cela comme tel, mais le problème que vous inquiéter est sur le point que votre nouvelle tête (avec le code instable) est la « pointe » de la branche par défaut.

De la Mercurial FAQ :

  

La pointe est toujours une tête. S'il y a   de multiples têtes dans un référentiel, seulement   l'un d'eux est la pointe. Dans un   dépôt, changesets sont numérotés   séquentiellement, de sorte que la pointe a la   le plus haut numéro de séquence. Le mot   fonctions « de pointe » comme une balise spéciale à   désigner la pointe de modifications, et il peut   être utilisé partout ou un ID tag changeset   est valide.

Il aurait été préférable d'avoir poussé ces changements à une branche nommée, comme Lasse suggère , mais vous êtes là où vous êtes. Dans ce cas, vous (ou un tirant ce référentiel pour la première fois) le besoin de mettre à jour la copie de travail à être sur la partie stable de votre succursale 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 à votre nouvelle branche copie de travail ne sera pas automatiquement mis à jour.

Answer 2

Cela a également été affiché sur la liste de diffusion Mercurial et au-dessous est ma réponse :

L'emplacement des deux branches (anonymes) dans la visionneuse de journal n'est pas important: il n'y a pas de gauche ou côté droit, l'ordre ne dépend que de l'ordre dans lequel vous avez fait des tractions et poussées

.

Qu'est-ce que vous avez besoin est un moyen de étiquette les changesets de l'écurie et les branches instables afin que vous puissiez garder une trace de ce qui est quoi. Il y a trois façons principales de le faire:

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

  Il a l'avantage que vous pouvez jeter les changesets facilement simplement supprimer le clone.

  Il a l'inconvénient que vous ne recevez pas vraiment un aperçu complet de ce qui se passe depuis les changesets sont maintenus isolés.

• branches nommées: Voir mon guide ici si vous ne l'avez pas déjà fait:

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

  L'avantage des succursales qui est qu'ils ont mis une étiquette dans chaque changeset afin que vous puissiez 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 nouveaux commits sont faits sur la branche, la pointe de la branche se déplace le long, et donc vous pouvez penser « refactoring-calendrier à Joda » comme une balise flottante.

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

   hg update default
  

  est où le développement normal doit avoir lieu.

  branches nommées sont bonnes pour les branches qui sont stables dans le temps plus long ou si le nom fait aussi des années plus tard sens. Par exemple, si vous utilisez un bug tracker, alors je suggère la création d'un bug pour suivre le refactoring, puis en appelant la branche « bug XX ». Que les gens peuvent rechercher le sens numéro de bogue droit à l'avenir.

• Favoris: 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 les signets de traction entre les dépôts.

utiliser des branches nommées pour les noms persistants à long terme, l'utilisation des signets pour les succursales de courte durée, et d'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 à branchement en mercurial /

Answer 3

Qu'est-ce que vous avez fait est très bien. Vous avez deux têtes sur la même branche nommée « par défaut ». Ceci est une façon tout à fait normal au travail. Voici une description assez décente de ce qui se passe:

http: // stevelosh .com / blog / 2009/08 / a-guide à branchement en mercure / # ramification anonyme

Comme Nick suggère, les gens qui ont déjà un clone obtiendra la nouvelle tête quand ils tirent et les personnes qui nouvellement clone obtiendrai à la fois -. Et c'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 il suffit de faire un plus engager avec le « Au lieu de limiter décimales de la monnaie ... » changeset comme parent comme ceci:

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 existait depuis longtemps avant qu'il avait nommé branches, donc tout ce que vous pouvez faire avec des branches nommées que vous pouvez faire avec des branches anonymes.

Si vous décidez d'avoir deux têtes non différenciées dans cette prise en pension est trop confus envisager de donner des signets un coup d'oeil. Ils sont des étiquettes adhésives qui permettent de suivre les conseils des branches anonymes -. Plus souples que les branches mentionnées dans ce qu'ils ne sont pas permanentes

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

Answer 4

Dans ce cas, vous devriez probablement attendre de pousser, et rendre l'ensemble du référentiel disponible.

Ou, lorsque vous avez commencé cette branche, vous devez avez donné un nom. Vous pouvez avoir plusieurs branches sans nom appartenant tous à la même branche nommée.

En d'autres termes, tous les changesets que vous voyez, il fait partie de la branche default, mais l'étiquette n'apparaît que la pointe de cette branche. Étant donné que les nouveaux changesets sont maintenant la pointe, c'est où l'étiquette est indiqué dans l'interface utilisateur.

Si vous aviez donné un nom, par défaut aurait encore été en panne sur votre changeset tipmost sur la branche par défaut.

Pour résoudre ce problème, vous auriez à « rejouer » les changesets un par un. Je ne sais pas la meilleure façon de le faire, mais il suffit de dire qu'ils obtiendraient de nouveaux hash, donc tout le monde qui a tiré ces changesets risque déjà les repousser dans le cadre de la branche par défaut.