多个分支的Mercurial存储库布局

Qua*_*um7 15 svn version-control mercurial project-management

我有许多准相关项目,我想版本控制.在SVN中,我将它们设置为单个项目中的多个目录

/scripts  #updates in sync with project1 & project2
/project1 #requires database
/project2 #requires database
/database
Run Code Online (Sandbox Code Playgroud)

当然,这个玩具示例可以使用其他SVN布局,但这种布局具有以下优点:

  • 我可以在分支之间复制文件,同时保留历史记录
  • 我只能查看一部分项目,例如svn co repo/project2; svn co repo/database.如果project1很大,这可以节省大量的存储和时间.
  • 易于存储库管理,因为所有项目都定义了一次用户访问权限

由于无法克隆mercurial repo的单个目录,因此这种范例不能很好地映射到mercurial .所以我的问题是:在mercurial中存储大型密切相关项目的最常用方法是什么?

我的想法:

  • 多个存储库 - 丢失在项目之间移动的文件的历史记录
  • 森林 - 似乎停滞不前,我不确定这个扩展是多么稳定
  • 命名分支,主要是不相关的内容
  • SubRepos - 不幸的是我正在运行Ubuntu 9.04,它只运送hg 1.1.2.否则这看起来是个不错的选择

Omn*_*ous 10

多个存储库,Forests和SubRepos都是同一个想法的变体.Forests和SubRepos只是使管理项目也更容易使用其他项目的最新版本,它们无法解决您遇到的基本问题,即在项目之间移动时丢失文件历史记录.

在我看来,最好的办法是将所有目录放在同一个存储库中,等待Mercurial功能允许签出子目录.子目录功能是Mercurial团队所关心的功能,但要做到这一点并非易事,这就是为什么还没有完成的原因.我知道Mercurial的内部结构,这绝对可行,只需要做很多工作.

第二个最好的选择,虽然我认为它真的很丑,但是你提到的命名分支机构的想法.尽管你想在分支机构之间复制文件,你仍然会有一个非常奇怪的合并操作.您将执行以下步骤:

  1. 更新要将文件复制到的分支的头部: hg update -C project1
  2. 合并要从中复制文件的分支: HGMERGE=/bin/false hg merge -r project2
  3. 恢复到要将文件复制到的分支的头部: hg revert -a --no-backup -r project1
  4. 从合并分支的头版本中还原要复制的特定文件: hg revert --no-backup -r project2 path/to/file/in/project2.txt
  5. 将文件移动到要将其复制到的分支中的位置: hg mv path/to/file/in/project2.txt project1/file/path/project2.txt
  6. 将合并标记为已解决: hg resolve -am
  7. 最后提交结果: hg commit -m "A merge to copy project2.txt to project1."

正如我所说,非常难看.它可能只适用于hg 1.3,因为我知道恢复,合并和解决的交互中的一些重要错误最近才被修复.(恕我直言,我怀疑Ubuntu是故意支持非bzr版本控制系统的版本.)

您经常期望在项目之间复制文件的频率如何?为什么会这样?你确定失败的历史会是一件坏事吗?

我已经在Subversion中为我自己的几个项目做了类似的事情,但我的经验是,我最初对某个项目真正属于哪个项目的感觉通常是正确的,而当它不保存历史时并不是那么大一段交易,因为历史真的只与原始项目有关,无论如何.