Mercurial Patch File d'attente Cas d'utilisation

Question

J'utiliser les patches mercuriels dans les cas suivants: -

1. Lorsque je dois tirer depuis un dépôt distant et ont des modifications non validées en suspens . Ensuite, je crée simplement un patch, qpop, tirez du dépôt distant, puis importer le patch à nouveau.
2. Quand je besoin de télécharger des correctifs à reviewboards . Je fais simplement un patch et de le transférer.

Sinon, comment utilisez-vous Mercurial Queues Patch? Je pense que son extension Mercurial très puissant et que je ne l'utilise pas à son plein potentiel.

Answer 1

Le wiki Mercurial a bonne section sur les cas d'utilisation:

En résumé:

1. Enregistrement de l'état actuel de la copie de travail de sorte que vous pouvez facilement y revenir plus tard
2. Prévenir une « copie de travail emmêlés » - si vous êtes à la moitié d'un changement et que vous voulez changer quelque chose d'autre
3. Fournir mutables, réarrangé commits de sorte que vous pouvez obtenir « l'histoire » à la recherche juste avant de pousser.

Answer 2

Vous n'avez pas vraiment besoin de patches Mercurial pour cela. Si vous avez des changements UNCOMMITED en cours lorsque vous tirez, ils seront fusionnés avec la pointe.

Exemple:

C:\>hg init db
C:\>cd db
C:\db>echo >file1
C:\db>echo >file2
C:\db>echo >file3
C:\db>hg ci -Am codebase          # Create a code base with 3 files.
adding file1
adding file2
adding file3
C:\db>echo a change >>file2       # Outstanding change to file2.
C:\db>hg st
M file2

À ce stade, nous allons cloner la base de données et un changement que commettons nous pouvons tirer.

C:\db>hg clone . \db2
updating to branch default
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
C:\db>cd \db2
C:\db2>echo a change >>file3
C:\db2>hg ci -m "file3 change"    # Commit a change to file3.

Retour dans la base de données originale ...

C:\db2>cd \db
C:\db>hg st                       # Still have uncommitted change
M file2
C:\db>hg pull \db2
pulling from \db2
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)
C:\db>hg st                       # We have the new history, but haven't updated.
M file2                           # file2 has uncommitted change.
C:\db>type file3                  # file3 is unchanged. 
ECHO is on.
C:\db>hg update
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
C:\db>hg st                       # We've updated, and file2 *still* has
M file2                           #    uncommitted change.
C:\db>type file2
ECHO is on.
a change
C:\db>type file3                  # But file3 now has committed change
ECHO is on.                       #    that was pulled.
a change

La morale est, vous pouvez simplement tirer et mettre à jour, même avec des modifications non validées. S'il y a des conflits de fusion, le comportement de fusion normale se produit aussi bien.

Pour l'exportation correctif hg export <rev> exportera correctifs pour examen.

Answer 3

Lorsque vous créez une file d'attente de patch sur Bitbucket, il énumère quelques-unes des utilisations les plus courantes pour les files d'attente de correctifs dans le volet de droite. Leur explication est très bonne et répond directement à votre question. Citations de ce sont ci-dessous.

files d'attente Patch sont bons pour:

  

  

• caractéristiques en développement vous avez l'intention de soumettre pour examen en amont

       

  Parce que les correctifs dans les files d'attente de patch peut   être modifiés, ils constituent un moyen idéal de   de développer une fonctionnalité dans un   de manière suivie l'histoire, tout en   vous permettant d'intégrer facilement   modifier

  

• Expérimenter avec l'ajout d'une nouvelle fonctionnalité

       

  files d'attente patch ne pas encombrer votre   l'histoire du projet, vous pouvez en toute sécurité   les utiliser comme un moyen d'essayer rapidement   une idée, et de le garder dans la version   le contrôle, sans encombrer votre   l'histoire du projet a échoué   excursions. Si vous décidez de garder la   expérience, vous pouvez facilement transformer un   file d'attente de patch dans un ensemble de traditionnel   commits Mercurial

  

• Le maintien de personnalisations privées pour un autre projet

       

  Parce que les files d'attente de patch ne font pas partie   le journal officiel de changement pour un projet,   elles sont idéales pour le maintien privé   personnalisations pour un en amont   projet. Par exemple, vous pouvez   maintenir un patch file d'attente qui rend   programme mieux intégrer à votre   le flux de travail de l'entreprise

  

files d'attente Patch sont pas bon pour

  

  

• branches de longue durée

       

  Parce que les files d'attente de patch sont très   volatile, ils font un mauvais suivi des travaux   l'histoire à long terme de la source   code. Pour cette raison, de longue durée   branches, telles que celles qui   correspondent aux rejets de produits, devrait   être conservés dans des dépôts ou du nom   branches.

  

• développement du Groupe

       

  files d'attente patch ne suivent pas la fusion   l'histoire, ce qui les rend pauvre   choix pour faire le développement du groupe,   où vous voulez vraiment voir quand un   ensemble donné de caractéristiques a été fusionné dans   un dépôt. En cas de doute, vous   devrait en tenir à une fourchette traditionnelle,   mais la maîtrise de la puissance du timbre   les files d'attente vous donnera énormément   flexibilité dans votre flux de travail, et   vous fournir grandement amélioré   capacités de collaboration.

  

Answer 4

MQ est un excellent outil pour gérer le développement simultané. auto-plagiat flagrant et l'auto-promotion de ma propre réponse :

  

3 Utilisation MQ avec un patch (ou plusieurs patchs consécutifs) par projet.

     

  
• Plus:. Simple et facile
  
• Inconvénients: doit qrefresh avant commutation et reconstruire après; rusé   et risqué si les projets ne sont pas   orthogonal.
  

     

4 Utiliser une branche MQ par projet.

     

  
• Pour: ultra flexible et extensible (pour le nombre de concurrent   projets)
  
• Inconvénients: doit qrefresh et qcommit avant commutation et la reconstruction après;   se sent compliqué.