Avec Mercurial, existe-t-il un moyen de sauvegarder rapidement dans un dépôt tmp?

Question

En utilisant un Macbook, je crains que si le disque dur est sur la route et qu'il se détériore, alors 3 jours de code peuvent tous être perdus.

J'ai donc un dépôt tmp sur notre serveur principal, et je peux le hg push. Le dilemme est, je ne peux pas pousser à moins que je commette d'abord, et de l'expérience précédente, nous ne devrions pas commettre à moins que nous soyons prêts à pousser à un serveur central (partager le code avec des collègues, fusionner, etc. nous ne pouvons pas pousser les fichiers sélectionnés - nous devons pousser tous les fichiers engagés ou ne rien pousser). Alors, comment résoudre cela? Existe-t-il un moyen de dire, "copier tous les fichiers MODIFIED (et les fichiers ajoutés) dans/user/peter/2010-06-18 sur le serveur central?)" Ou ne pas commettre mais en quelque sorte l'obtenir sur le serveur?

Answer 1

La méthode normale consiste à simplement valider. Avec un DVCS on est invité à "s'engager tôt, commettre souvent". Commit localement souvent, puis à des fins de sauvegarde, poussez fréquemment votre tmp repo sur le serveur. Lorsque vous êtes satisfait de votre travail, alors vous poussez de votre repo tmp à votre serveur "central" partagé.

Il n'est pas nécessaire de s'assurer que tout se compile après chaque modification, la norme est de s'assurer que chaque retour de changesets que vous avez poussé laisse la 'tip' dans un état compilable. Généralement, on déclenche le serveur de construction d'intégration continue pour activer une génération après que chaque groupe de changesets (groupe de changements) arrive, et il considère seulement la 'pointe'. Si vous ne pouvez pas vraiment avoir des changesets qui ne peuvent pas se suffire à eux-mêmes, alors un pro mercurial utilisera mercurial queues pour garder un correctif versionné dans un dépôt de file d'attente séparé tout en travaillant dessus. Quelqu'un prêt à jouer avec le feu utiliserait l'extension collapse pour fusionner la séquence des changesets en un seul changeset avant de pousser vers les repos partagés.

Parmi les trois options présentées:

1. fixer votre flux de travail afin que le repo central peut gérer changesets qui ne compilent pas, tant qu'ils font partie d'un changegroup qui compile
2. Mercurial les files d'attente pour garder un patch dans un référentiel de correctifs versionné
3. utiliser l'extension de l'effondrement de réécrire l'histoire (jouer avec le feu)

Je pense que le premier est le plus souvent fait, et g énéralement le "juste" chemin.