2011-01-14 2 views
2

Avant, lorsque j'utilisais perforce, je pouvais travailler sur plusieurs bogues à la fois tant que le code n'affectait pas les mêmes fichiers, en ayant plusieurs ensembles de changements ouverts en même temps.Mercurial: Multiple Change définit à la fois?

Changeset 1:


  • A.txt
  • B.txt sont capturés
  • C.txt

Changeset 2:


  • d.txt
  • f.txt
  • f.txt

je pouvais soumettre 2 changeset au référentiel sans soumettre changeset 1 (car il est encore en cours)

Est-ce possible avec Mercurial? autre que de faire chaque fichier en tant que commit séparé?

Répondre

2

Vous pouvez avoir deux branches distinctes (copies de travail) et effectuer une modification dans l'autre et dans l'autre. C'est un moyen. Un autre est d'utiliser Mercurial Queues. Vous pouvez utiliser qpush --move pour changer l'ordre des changesets s'ils n'ont pas de dépendances les uns sur les autres, ainsi vous pouvez utiliser qfinish pour 'valider' le premier changeset qui est prêt.

2

Vous ne possédez pas réellement les changesets "ouverts" dans Mercurial.

Soit vous avez validé vos modifications, soit vous ne l'avez pas fait.

Vous pouvez cependant avoir plusieurs fichiers avec des modifications non validées, et ne valider que quelques-uns d'entre eux. Il est même possible de valider des parties de fichiers, des morceaux, au lieu du fichier entier.

Si je devais faire ce que vous me demandez, je créerais simplement un autre clone localement à partir de mon premier, et travaillerais sur les deux correctifs différents dans deux dossiers de travail différents. Ensuite, j'ai toute la liberté dont j'ai besoin pour combiner les deux (pousser/tirer localement), pousser sur le serveur, etc

3

Vous pouvez toujours faire: hg commit D.txt E.txt F.txt pour ne commettre que les fichiers qui laisseront A.txt, B .txt, et C.txt uncommited. L'utilisation de l'option -I pour valider vous permet de faire ceux avec des motifs s'ils sont, par exemple, dans un répertoire commun: hg commit -I 'dir1/**'

0

Dans Mercurial, le clonage est une opération bon marché lorsqu'il est effectué localement. Il suffit de cloner le référentiel pour chaque chose sur laquelle vous travaillez. Appuyez sur le référentiel principal que chaque chose est prêt:

hg clone http://project project 
hg clone project project-bugfix // uses hardlinks and is inexpensive. 
hg clone project project-feature 
<edit bugfix and feature as needed> 

Mais rappelez-vous que l'emplacement de poussée par défaut est le projet cloné à partir, vous devrez soit modifier .hg \ chemin push par défaut de hgrc pour la " projet "clones, ou assurez-vous de hg push http://project de" projet-bugfix "et" project-feature "lorsque vous avez terminé.

+1

Le clonage est pas cher oui, mais la mise en place de mon environnement de développement est un processus très coûteux. –

+0

Ensuite, je recommande des files d'attente de patch ou des branches nommées. ou utilisez des chemins relatifs plutôt que des chemins codés en dur dans vos projets; ^) –

0

Même si vos modifications touchent le même fichier, vous pouvez sélectionner les éléments à inclure (morceau par morceau). Il vous suffit d'activer l'extension record (elle est installée par non activée par défaut).

Pour activer l'extension d'enregistrement, mettez cela dans la section [extensions] de votre .hgrc:

[extensions] 
hgext.record= 

Puis commettras, remplacer hg commit par hg record. Supposons que votre exemple change les ensembles avec un fichier G.txt qui a des modifications pour les deux ensembles de modifications. Commit avec:

hg record D.txt E.txt F.txt G.txt 

Répondre à des questions, par exemple:

2 hunks, 6 lines changed 
examine changes to 'D.txt'? [Ynsfdaq?] f  # f for full file (help with ?) 
... skipped file E and F 
6 hunks, 35 lines changed 
examine changes to 'G.txt'? [Ynsfdaq?] y 
@@ ... (patch hunk here) 
record change 6/16 to 'G.txt'? [Ynsfdaq?] y # y to include the hunk, n to skip 
Questions connexes