多个分支的Mercurial存储库布局 [英] Mercurial repository layout for multiple branches
问题描述
我有许多要进行版本控制的与准相关的项目.在SVN中，我会将它们设置为单个项目中的多个目录
I have a number of quasi-related projects that I want to version control. In SVN I would set them up as multiple directories within a single project
/scripts #updates in sync with project1 & project2
/project1 #requires database
/project2 #requires database
/database
对于这个玩具示例，自然也可以使用其他SVN布局，但是这种布局具有优势:
Naturally other SVN layouts are possible for this toy example, but this layout has advantages:
- 我可以在保留历史记录的同时在分支之间复制文件
- 我只能签出一部分项目，例如
svn co repo/project2; svn co repo/database. 这节省了大量的存储空间. project1很大的时间. - 易于存储库管理，因为对所有项目都只定义了一次用户访问权限
- I can copy files between branches while preserving history
- I can check out only a subset of projects, eg
svn co repo/project2; svn co repo/database. This saves a considerable amount of storage & time if project1 is large. - Easy repository management, since user access is defined once for all projects
This paradigm doesn't map well to mercurial since you can't clone a single directory of a mercurial repo. So my question is: what is the most common way to store large, closely related projects in mercurial?
我的想法:
- 多个存储库-丢失在项目之间移动的文件的历史记录
- 森林-似乎停滞了，我不确定此扩展的稳定性如何是
- 具有大部分不相关内容的命名分支
- SubRepos -不幸的是，我正在运行Ubuntu 9.04，该版本仅随附汞1.1 .2.否则，这似乎是一个不错的选择
- Multiple repositories - loses history of files which move between projects
- Forests - seems stalled, and I'm not sure how stable this extension is
- Named branches with mostly unrelated content
- SubRepos - Unfortunately I'm running Ubuntu 9.04, which only ships hg 1.1.2. Otherwise this would look like a good option
推荐答案
多个存储库，森林和SubRepos都是同一想法的变体. Forests和SubRepos只是使管理也使用其他项目的最新版本的项目变得更加容易，它们不能解决您遇到的基本问题，即在项目之间移动它们时会丢失文件历史记录.
Multiple repositories, Forests and SubRepos are all variants on the same idea. Forests and SubRepos just make managing projects that also use extremely recent versions of other projects easier, they don't solve the basic problem you have, which is that you lose file history when moving them between projects.
我认为，最好的选择是将所有目录放在同一存储库中，并等待Mercurial功能允许签出子目录.子目录功能是Mercurial团队关心的一项功能，但这也不是一件容易的事，这就是为什么尚未完成的原因.我知道Mercurial内部原理，而且确实很可行，只需要做很多工作即可.
In my opinion, your best bet is to put all the directories in the same repository and wait for the Mercurial feature to allow checkout of subdirectories. The subdirectory feature is one the Mercurial team cares about, but it's not trivial to do either, which is why it hasn't been done yet. I know the Mercurial internals though, and it's definitely doable, just a lot of work.
第二个最好的选择是您提到的命名分支的想法，尽管我认为这很丑陋.但是，无论何时要在分支之间复制文件，您仍将执行非常奇怪的合并操作.您将执行以下步骤:
The second best option, though I consider it really ugly, is the named branches idea you mentioned. You will still have a very weird merge operation to perform whenever you want to copy files between branches though. You will perform these steps:
- 更新到要将文件复制到的分支的开头:
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."
- Update to head of the branch you want to copy the file into:
hg update -C project1 - Merge in the branch you want to copy the file from:
HGMERGE=/bin/false hg merge -r project2 - Revert to the head of the branch you want to copy the file into:
hg revert -a --no-backup -r project1 - Revert the specific file you want to copy from the head revision of the merged in branch:
hg revert --no-backup -r project2 path/to/file/in/project2.txt - Move the file into it's place in the branch you want to copy it to:
hg mv path/to/file/in/project2.txt project1/file/path/project2.txt - Mark the merge as resolved:
hg resolve -am - And finally commit the result:
hg commit -m "A merge to copy project2.txt to project1."
正如我所说，非常丑陋.而且它可能只能在hg 1.3中很好地工作，因为我知道还原，合并和解析交互中的一些重要错误是最近才修复的. (恕我直言，我怀疑Ubuntu在非bzr版本控制系统的版本上故意落后了.)
As I said, very ugly. And it might well only work well in hg 1.3 since I know some important bugs in the interaction of revert, merge and resolve were fixed fairly recently. (IMHO, I suspect Ubuntu is purposely behind on versions of non-bzr version control systems.)
您真的希望多久在项目之间复制一次文件?为什么会发生呢?您确定失去历史将是一件坏事吗?
How often do you really expect to be copying files between projects? Why would it happen? Are you sure that losing history would be that bad of a thing?
我已经为自己的几个项目在Subversion中做过类似的事情，但是我的经验是，我最初对某个项目真正属于哪个项目的初衷通常是正确的，并且在不保存历史的时候并没有确实是一件大事，因为历史实际上只与文件所涉及的原始项目有关.
I've done something similar in Subversion for a couple of projects of my own, but my experience is that my initial feeling about which project something really belonged in was usually correct, and when it wasn't preserving history wasn't really that big a deal since the history was really only relevant to the original project the file was in anyway.
这篇关于多个分支的Mercurial存储库布局的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
