AppHarbor、BitBucket 和 SubRepo 变通答案

【问题标题】：AppHarbor, BitBucket and SubRepo Work AroundAppHarbor、BitBucket 和 SubRepo 变通
【发布时间】：2012-07-22 15:20:01
【问题描述】：

我想在AppHarbor 上主持一个项目。该项目的Hg 存储库托管在BitBucket 上。问题是我的存储库包含一个子存储库（在BitBucket 上也是Hg）。看来AppHarbor 没有办法拉取subrepos，所以项目构建失败。

AppHarbor 已意识到该问题并表示解决方案取决于BitBucket：

BitBucket 有一张开放的票，但没有更新：

https://bitbucket.org/site/master/issue/1500/archived-snapshots-dont-contain-subrepo

我的问题是，有人对此有很好的解决方法吗？我愿意将工作目录ftp 到AppHarbor，但我不知道该怎么做。

【问题讨论】：

标签： mercurial bitbucket appharbor mercurial-subrepos

【解决方案1】：

Bitbucket 修改存档 tarball 以包含子存储库可能不合适。

但是，您可以轻松设置一些东西来构建您自己的 tarball，appharbor 可以处理这些 tarball，并将它们提供给 appharbor。在某处运行的 cron 作业仅执行 hg pull ; hg update ; tar -czvf /docroot/workingdir.tar.gz workingdir 就足以创建应用程序港口可以使用的 Web 可访问 tarball。

更好的解决方法是让 app Harbor 进行克隆和更新，而不是下载 tarball。 Mercurial 和 git 具有获取代码的内置方法，而 tarball 是一种后备机制，而不是主要机制。例如，像 Jenkins 这样的流行 CI 系统使用克隆来获取代码，而不是 tarball 下载，因此它们可以正常工作。

【讨论】：

我可能会不情愿地设置它。我确实希望 AppHarbor 会进行克隆 + 更新。 Subrepos 似乎可以很好地用于开发目的。我不知道 AppHarbor 的案例有什么区别让他们选择了 tarball 方法。
我们不克隆存储库有几个原因：1）我们有许多构建引擎在运行，所以我们每次都必须进行完整克隆（这比只是接收文件的当前版本）。 2) 我们支持多种版本控制风格，因此我们必须维护 Git、Mercurial、Subversion 和 TFS，这并没有真正为我们的核心产品提供任何价值。
我一直不明白为什么 Bitbucket 和 GitHub 也不提供打包子存储库的选项。您的存储库可能依赖于其中的一些内容，因此忽略它们并没有真正的帮助。
虽然它可能超出了您的项目的范围，但您实际上可以使用our build API 创建一个中介，首先克隆存储库，然后将其很好地打包，包括子存储库的内容。如果有人提供这样的服务，我们肯定会引导用户使用它。