Mercurial commit sur le nouveau dépôt

J'ai un plan Bamboo qui exécute un script pour construire un projet. Le script met à jour les fichiers AssemblyInfo.cs dans la solution jusqu'au numéro de build suivant, puis valide la modification et effectue une extraction pour fusionner les modifications et éviter d'avoir plusieurs têtes.Mercurial commit sur le nouveau dépôt

hg commit -m "$(Major).$(Minor).$(Build).$(Revision)" 
hg fetch

La sortie de bambou finit par être:

02-Jul-2012 07:50:11 CommitChanges: 
02-Jul-2012 07:50:11 Commiting version number changes for d:\Builds\TDFGE-DRD-JOB1 
02-Jul-2012 07:50:11 hg commit -m "1.0.0.6" 
02-Jul-2012 07:50:12 created new head 
02-Jul-2012 07:50:12 hg fetch 
02-Jul-2012 07:50:12 abort: multiple heads in this branch (use "hg heads ." and "hg merge" to merge) 
02-Jul-2012 07:50:12 d:\Builds\TDFGE-DRD-JOB1\Build.proj(96,3): error MSB3073: The command "hg fetch" exited with code 255. 
02-Jul-2012 07:50:12 Done Building Project "d:\Builds\TDFGE-DRD-JOB1\Build.proj" (UpdateVersionAndBuild target(s)) -- FAILED. 
02-Jul-2012 07:50:12 
02-Jul-2012 07:50:12 Build FAILED.

Les docs pour Mercurial dit que Fetch devrait obtenir le dernier code et fusionner les modifications.

Cela semble être une tâche très simple, changer certains fichiers, les vérifier, continuer. Alors qu'est-ce qui me manque ici? Ai-je besoin de faire une fusion ou quelque chose? PS. J'ai essayé d'ajouter une autre fusion/validation après la validation d'origine (cela ne semblait pas correct, mais cela s'est terminé), mais les fichiers repassés dans le référentiel principal avaient toujours l'ancien numéro de version, ils étaient inchangés. On dirait que la commande merge a pris le référentiel principal en tant que parent principal.

Source

2012-07-02 Tyrel Van Niekerk

Je peux exécuter cette commande localy toute la journée, aucun problème, pas de têtes multiples. La seule différence que je peux penser est que, dans TortoiceHg Workbench, j'ai vérifié checkbok (résoudre automatiquement les conflits de fusion si possible) dans la boîte de dialogue Post Pull Behavior. Je ne sais pas si cela fait une différence, mais ça pourrait le faire. –

Également exécuté la commande localement en tant qu'utilisateur de génération dans le même dossier que lorsque Bamboo l'exécute et cela fonctionne. Est-ce que HG agit différemment lorsque l'utilisateur s'exécute en tant que service? –

Semble la réponse à la fin n'était pas ce que je cherchais. Je ne sais toujours pas pourquoi HG avait des problèmes, mais il est probablement impossible de mettre à jour et de valider les changements de numéro de version. Je suppose que la raison pour laquelle il n'y a pas de chemin vers le dépôt principal pour les déploiements de Bamboo est que cela provoquerait le démarrage d'un autre déploiement de bambou à cause de la validation et provoquerait une boucle infinie de constructions. En fin de compte j'ai changé le code pour juste mettre à jour les fichiers, construire, créer le paquet NuGet et être fait.

Source

2012-07-02 16:27:50

Au cas où quelqu'un rencontrerait le même problème. Je crois que la raison pour laquelle le commit n'a pas été pris est que bamboo a un cache de dépôt sur le serveur ci. Le référentiel de travail est cloné à partir du référentiel de cache, donc toutes les poussées iront dans le repo du cache et non sur bitbucket.

Pour contourner ce problème, j'appuie explicitement sur le rapport hébergé.

hg pousser https://user:[email protected]/myrepo

Source

2014-07-31 19:05:47 Avner

Mercurial commit sur le nouveau dépôt

Répondre

Questions connexes