bonjour,
j'ai un projet géré par mercurial pour la gestion du code. Ça fonctionne bien, seulement parfois (aléatoirement) quand je fais un commit, alors que je n'ai que 2 ou 3 fichiers de modifiés, ça m'en rajoute une dizaine de plus dans le commit : ça indique des modifications déjà effectuées plusieurs mois auparavant, qui n'ont rien à faire dans le commit en question.
Savez-vous d'où ça pourrait venir ?
# contexte
Posté par GeneralZod . Évalué à 3.
C'est soit un bogue grave, soit tu as fait une mauvais manipulation quelque part (checkout ? plugin foireux ? etc...)
Est-ce que ça arrive sur un clone propre et sans plugin actif ?
[^] # Re: contexte
Posté par B16F4RV4RD1N . Évalué à 2.
voir réponse plus bas.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
# Pas assez d'infos...
Posté par ymorin . É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.
[^] # Re: Pas assez d'infos...
Posté par zerkman (site web personnel) . Évalué à 2.
il n'y a pas de branches locales dans Hg ?
[^] # Re: Pas assez d'infos...
Posté par ymorin . Évalué à 2.
Ça évite d'avoir à faire 'make distclean' avant de passer d'une branche à l'autre.
Comme ça, les deux clones sont toujours prêts.
Hop,
Moi.
[^] # Re: Pas assez d'infos...
Posté par GeneralZod . Évalué à 3.
Si, tu as les branches nommés (pas d'équivalent dans Git) et les bookmarks (équivalent des branches git) qui jusqu'à la version 1.8 était une extension officielle.
Ce qui lui faudrait c'est une fonctionnalité ala git stash (le plus proche c'est l'extension shelve non-officielle)
[^] # Re: Pas assez d'infos...
Posté par ymorin . Évalué à 2.
Je préfère les MQs. Il est possible d'avoir plusieurs MQs dans un même clone, et on peut passer de l'une à l'autre.
Le problème, pour moi, n'est pas de différencier les différents 'flux' (stream) de développement, mais plutôt d'éviter de re-compiler le projet en passant d'un flux à l'autre.
Mais tout ça ne résout pas le shmilblick de l'OP.
[^] # Re: Pas assez d'infos...
Posté par B16F4RV4RD1N . Évalué à 2.
en fait effectivement il manquait une donnée, je viens de remarquer que ça arrive quand je change de machine depuis laquelle je fais les commit : en effet, j'ai 2 ordinateurs de travail, que je synchronise avec unison. Le répertoire où se trouve le projet en question est un sous répertoire de mon dossier de travail principal, synchronisé régulièrement (je me vois mal exclure ce répertoire de la synchro unison, puis faire des pull depuis mercurial et hg update, même si c'est sans doute la méthode préconisée dans un cas comme cela).
Il est possible que si les dates diffèrent un peu, ça puisse générer ces comportements étranges. Je n'ai pas souvenir d'avoir eu la même chose avec SVN.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Pas assez d'infos...
Posté par ymorin . Évalué à 2.
Alors là, tu cherches les ennuis ! :-)
Je ne sais vraiment pas comment Hg se comporte dans ce cas (je ne connais pas non plus unison) :
PC1:
$ hg clone URL/prj; cd prj
$ vi file-1 # Modifs bla-bla
$ hg ci file-1 # pas de push -> URL
PC2:
$ hg clone URL/prj; cd prj
$ vi file-1 # Modifs titi-toto
$ hg ci file-1 # Pas de push -> URL
$ unison-sync --from=PC1 --to=PC2
Maintenant, dans quel état sont les méta-données de Hg ( le contenu de .hg/ ) ? Mystère et boule de gomme... :-/
Hop,
Moi.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.