Mercurial在新存储库上提交

时间:2012-07-02 12:23:09

标签: mercurial bamboo

我有一个Bamboo计划,它运行一个脚本来构建项目。该脚本将解决方案中的AssemblyInfo.cs文件更新为下一个构建号,然后提交更改并进行提取以合并任何更改并避免获得多个头。

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

Bamboo的输出结果是:

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. 

Mercurial的文档说Fetch应该获取最新代码并合并任何更改。

这似乎是一个非常简单的任务,更改一些文件,检查它们,继续。那我在这里错过了什么?我需要合并吗? PS。我确实尝试在原始提交之后添加另一个合并/提交(似乎不正确,但它已完成),但随后推回到主存储库的文件仍具有旧版本号,即它们未更改。似乎merge命令将主存储库作为主要父级。

2 个答案:

答案 0 :(得分:0)

似乎答案到底不是我想要的。仍然不确定为什么HG遇到了它所遇到的问题,但是可能无法更新和提交版本号更改。我的猜测是没有路径回到Bamboo部署的主存储库的原因是因为这会导致另一个竹子部署因为提交而启动并导致无限循环的构建。

最后,我将代码更改为只更新文件,构建,创建NuGet包并完成。

答案 1 :(得分:0)

如果有人遇到同样的问题。我认为提交没有采取的原因是Bamboo在ci服务器上有一个存储库缓存。作业存储库是从缓存存储库克隆的,因此任何推送都将转到缓存仓库,而不会转到bitbucket。

为了解决这个问题,我明确地推送到托管仓库。

hg push https://user:password@bitbucket.org/myrepo