Il n'y a pas assez d'infos pour suggérer la bonne piste...
J'utilise Hg depuis plus de deux ans, tous les jours, à lq fois en tant que développeur et en tant que mainteneur. Je n'ai jamais, jamais, observé un tel comportement...
Ceci dit, est-ce que ta procédure de génération peut toucher aux fichiers en confs? Par exemple, des Makefiles modifiés...
Je n'ose pas imaginer un time-drift. Plusieurs mois de time-drift, c'est cheulou, tu t'en serais (j'espère!) déjà rendu compte...
Il est possible aussi que tu ai 'oublié' de comitter ces changements. Si tu fais des commits explicites à chaque fois (eg. hg ci file1 file2) plutôt que global (hg ci .), alors au check-in global suivant, tu vas te traîner les reliquats non committés.
Pareil, si tu as oublié d'ajouter (hg add) ou d'enlever (hg delete ou hg forget), le prochain vas trouver ces reliquats.
Un cas concret qui m'est arrivé : j'ai deux clones, l'un pour quelques tests, et l'un de dev principal. Normalement, je ne commite rien dans le clone de test, je fais que des pull. Sauf qu'une fois, j'ai du reporter à la main quelques lignes de dev vers le test juste pour voir (quand on en est au 12ème patch MQ, on n'a pas forcement envie de finir la MQ pour récupérer dans un autre clone). Un peu plus tard, j'ai fait un quick-fix dans le clone de test, et comme il était bon, j'ai voulu le committer. Et là, c'est la cata... Je me retrouve avec ces p*t@!n5 de modifs dont je voulais pas...
Bref, un très bon outil comme Hg ne suffit pas a régler tous les problèmes. Il faut aussi un workflow correct, auquel on doit se tenir.
Par exemple, je ne fais quasi jamais de commit direct. J'utilise quasi-exclusivement une MQ, même pour un seul patch. Ça permet d'éviter tout erreur, et de corriger le tir si nécessaire. Sans compter le nombre de fois où un quick-fix en nécessite un autre ailleurs, et du coup, il faut deux commits; les MQs permettent de gérer ça vraiment très bien! Et viva las MQ!
# Pas assez d'infos...
Posté par ymorin . En réponse au message Mercurial : révision aléatoire pour des changements inexistants. Évalué à 3.
Il n'y a pas assez d'infos pour suggérer la bonne piste...
J'utilise Hg depuis plus de deux ans, tous les jours, à lq fois en tant que développeur et en tant que mainteneur. Je n'ai jamais, jamais, observé un tel comportement...
Ceci dit, est-ce que ta procédure de génération peut toucher aux fichiers en confs? Par exemple, des Makefiles modifiés...
Je n'ose pas imaginer un time-drift. Plusieurs mois de time-drift, c'est cheulou, tu t'en serais (j'espère!) déjà rendu compte...
Il est possible aussi que tu ai 'oublié' de comitter ces changements. Si tu fais des commits explicites à chaque fois (eg. hg ci file1 file2) plutôt que global (hg ci .), alors au check-in global suivant, tu vas te traîner les reliquats non committés.
Pareil, si tu as oublié d'ajouter (hg add) ou d'enlever (hg delete ou hg forget), le prochain vas trouver ces reliquats.
Un cas concret qui m'est arrivé : j'ai deux clones, l'un pour quelques tests, et l'un de dev principal. Normalement, je ne commite rien dans le clone de test, je fais que des pull. Sauf qu'une fois, j'ai du reporter à la main quelques lignes de dev vers le test juste pour voir (quand on en est au 12ème patch MQ, on n'a pas forcement envie de finir la MQ pour récupérer dans un autre clone). Un peu plus tard, j'ai fait un quick-fix dans le clone de test, et comme il était bon, j'ai voulu le committer. Et là, c'est la cata... Je me retrouve avec ces p*t@!n5 de modifs dont je voulais pas...
Bref, un très bon outil comme Hg ne suffit pas a régler tous les problèmes. Il faut aussi un workflow correct, auquel on doit se tenir.
Par exemple, je ne fais quasi jamais de commit direct. J'utilise quasi-exclusivement une MQ, même pour un seul patch. Ça permet d'éviter tout erreur, et de corriger le tir si nécessaire. Sans compter le nombre de fois où un quick-fix en nécessite un autre ailleurs, et du coup, il faut deux commits; les MQs permettent de gérer ça vraiment très bien! Et viva las MQ!
Hop,
Moi.