Puis-je marquer un fichier dans mercurial comme "ne jamais valider ce fichier"?

Question

Dans notre application, l'utilisateur peut naviguer entre les pages en utilisant la barre d'outils, et la page 1 est affichée par défaut. Je modifie la page 3a, qui n'est accessible que par quelques clics de la barre d'outils. C'est ennuyeux à faire pendant le débogage, donc dans main.cpp j'ai mis la valeur par défaut à la page 3a, mais je ne veux certainement pas vérifier cela. Cependant, Mercurial me dit constamment que main.cpp est modifié (de bien sûr), et cela interfère avec des choses comme les fusions.

Je voudrais déplacer main.cpp dans une liste spéciale dans Mercurial qui est fondamentalement, "oui, je sais que ce fichier est modifié, ne vous inquiétez pas à ce sujet". Notez que l'extension Shelf n'est pas tout à fait ce que je veux, car main.cpp reviendra à son état d'origine. Je ne veux pas non plus "oublier" le fichier. Quelqu'un at-il une solution pour cela?

(mods: ne hésitez pas à modifier cette question pour être plus concis)

Answer 1

Si cela était plus court, je l'aurais ajouté comme commentaire à la réponse de pyfunc, puisque c'est juste en ajoutant un peu d'info.

Il y a deux questions, apparemment:

1. Allow sans commettre commettras main.cpp
2. Allow tire sans perdre les modifications MAIN.CPP

Pour ajouter à la suggestion de commettre exclure Pour (1), si vous pouvez utiliser TortoiseHg, il offre une liste d'exclusion de commit sans l'inconvénient de la section par défaut et sans avoir besoin de se rappeler si vous avez besoin d'utiliser un alias sur ce projet particulier. Vous pouvez lire sur mon expérience avec elle here.

Il n'y a pas de réponse pour (2). Tandis que Shelve fait quelques pas, vous allez devoir travailler parce que Mercurial échouera avec les changements locaux, c'est aussi simple que ça. Je recommanderais mq car Tortoise fournit une belle intégration avec la boîte de dialogue de validation, mais ce n'est vraiment pas plus simple que de mettre en veille dans le cas d'un fichier modifié.

Ce n'est vraiment pas difficile d'utiliser shelve ou mq, par conséquent, je ne m'en soucierais pas trop.

Answer 2

Comme Chris a souligné dans les commentaires de la façon rapide et sale pour le faire est d'utiliser le mécanisme que je suggère dans une autre question. La meilleure façon de le faire est un engagement crochet qui empêche commits y compris ce fichier:

[hooks] 
pretxncommit.nomain = sh -c "! hg log -r tip --template '{files}' | grep -q /main.cpp" 

Vous avez encore de se rappeler de ne pas inclure main.cpp dans votre ligne commit, mais quand vous oubliez le commettras refusera de commettre .

Answer 3

Aucune extension ne vous permet d'ignorer un fichier déjà suivi par Mercurial.

Cependant, il existe peu d'approches que vous pouvez suivre.

Comme Ry4an suggèrent, commits de bloc qui incluent le fichier puis effectuez une explicite

hg commit file1, file2, ... 

Une autre approche élégante est de dire la méthode de validation d'ignorer certains types de fichiers en commettant des fichiers.

J'aime mieux cette approche.

hg commit --help 
....... 
-X --exclude PATTERN [+] exclude names matching the given patterns 

Exemple:

say I have two files a.py, b.py in my repo. I have changed them both. 
hgt $ hg status 
M a.py 
M b.py 
hgt $ hg commit -X a.py -m "Added new line to b.py" 
hgt $ hg status 
M a.py 

Answer 4

Ceci est en fait un modèle d'utilisation assez courante. Pour un seul fichier, l'option -X ou le rayonnage et le déstockage selon les besoins est probablement la méthode la plus simple, mais comme d'habitude pour DVCS, la solution la plus générale consiste à créer une autre branche. Un exemple de cela (pour bzr, mais les principes s'appliquent) est trouvé here. Fondamentalement, vous démarrez avec votre branche publique qui reflète la branche en amont. De là, vous branchez une branche "local changes", où vous effectuez la modification de main.cpp. À partir de cette branche «changements locaux», vous créez votre branche de fonctionnalité, où vous effectuez votre travail quotidien normal, en vous engageant normalement.

Lorsque vous êtes prêt à partager vos modifications, vous pouvez les récupérer dans votre première branche, obtenant ainsi les modifications que vous venez de faire sans les modifications locales de main.cpp. En utilisant cette méthode, vous pouvez même faire des corrections publiques à main.cpp sans que votre hack de débogage local ne soit enregistré. L'inconvénient est une complexité supplémentaire sur les pulls et les fusions, car ils doivent d'abord passer par les branches amont et local Gardez la pioche propre.