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中存储大型密切相关项目的最常用方法是什么?
我的想法:
Omn*_*ous 10
多个存储库,Forests和SubRepos都是同一个想法的变体.Forests和SubRepos只是使管理项目也更容易使用其他项目的最新版本,它们无法解决您遇到的基本问题,即在项目之间移动时丢失文件历史记录.
在我看来,最好的办法是将所有目录放在同一个存储库中,等待Mercurial功能允许签出子目录.子目录功能是Mercurial团队所关心的功能,但要做到这一点并非易事,这就是为什么还没有完成的原因.我知道Mercurial的内部结构,这绝对可行,只需要做很多工作.
第二个最好的选择,虽然我认为它真的很丑,但是你提到的命名分支机构的想法.尽管你想在分支机构之间复制文件,你仍然会有一个非常奇怪的合并操作.您将执行以下步骤:
hg update -C project1
HGMERGE=/bin/false hg merge -r project2
hg revert -a --no-backup -r project1
hg revert --no-backup -r project2 path/to/file/in/project2.txt
hg mv path/to/file/in/project2.txt project1/file/path/project2.txt
hg resolve -am
hg commit -m "A merge to copy project2.txt to project1."
正如我所说,非常难看.它可能只适用于hg 1.3,因为我知道恢复,合并和解决的交互中的一些重要错误最近才被修复.(恕我直言,我怀疑Ubuntu是故意支持非bzr版本控制系统的版本.)
您经常期望在项目之间复制文件的频率如何?为什么会这样?你确定失败的历史会是一件坏事吗?
我已经在Subversion中为我自己的几个项目做了类似的事情,但我的经验是,我最初对某个项目真正属于哪个项目的感觉通常是正确的,而当它不保存历史时并不是那么大一段交易,因为历史真的只与原始项目有关,无论如何.