使用mercurial合并cvs分支

发布于 2024-10-07 12:55:25 字数 452 浏览 0 评论 0原文

目前我公司正在使用cvs进行版本控制。我们有一个旧的代码分支,专门用于一个客户端(不要问),我们希望将其合并到头部。

由于这个分支和头部之间的差异,我认为 Mercurial 的合并功能应该会让我的工作变得更容易一些。我的推理是:

  1. 创建分支和当前负责人的 Mercurial 存储库。
  2. 将分支存储库合并到主干存储库。

在这个阶段,我期待 Mercurial 提供更好的 合并支持比cvs。

然后我将对主干存储库的更改提交回 cvs。

这种方法合理吗?这个策略是否会像我想象的那样让合并变得不那么痛苦,或者我遗漏了什么?

Currently my company is using cvs for version control. We have an old branch of code which has been used specifically for one client (don't ask) that we'd like to merge to the head.

Due to the delta between this branch and the head I think the merging capabilities of mercurial should make my job a bit easier. My line of reasoning is:

  1. Create mercurial repositories of the branch and the current head.
  2. Do a merge of the branch repo to the trunk repo.

At this stage I'm expecting mercurial to provide better merge support than cvs.

Then I would commit my changes to the trunk repository back into cvs.

Is this approach sound? Will this strategy result in a less painful merge as I think it will, or is there something I'm missing?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

热风软妹 2024-10-14 12:55:25

Mercurial 比 CVS 或 Subversion 合并得更好的原因是它跟踪两个头/分支的最近共同祖先,因此您需要确保准确地提供该信息,否则您可能会得到更糟糕的合并结果。

如果你这样做:

hg init newrepo
cd newrepo
cvs checkout POINT_OF_DIVERGENCE
hg commit --addremove -m 'commiting point of divergence'
cvs checkout BRANCH
hg addremove --similarity 90 # let Mercurial discover any renames
hg commit -m 'committing branch head'
hg update -r 0               # jump back to point of divergence
cvs checkout HEAD
hg addremove --similarity 90 # let Mercurial discover any renames
hg commit -m 'commiting HEAD head'
hg merge

那么两个头的共同祖先将是分歧点(抱歉,如果 CVS 命令错误,这已经是很长一段时间了)。

麻烦在于知道 POINT_OF_DIVERGENCE 在 CVS 存储库中的位置——CVS 根本不跟踪它,这就是为什么它自己的合并不使用它。

CVS 最佳实践总是建议,每当您进行分支时,您都创建一个标记分歧点的标签,但如果您不这样做,那么您前面就会遇到一些棘手的问题。

如果没有正确的最近共同祖先,Mercurial 合并不会比 CVS 更好。

The reason Mercurial merges better than CVS or Subversion is because it tracks the most recent common ancestor of the two heads/branches, so you'll to make sure you're providing that information accurately or you'll probably end up with a worse merge.

If you do something like this:

hg init newrepo
cd newrepo
cvs checkout POINT_OF_DIVERGENCE
hg commit --addremove -m 'commiting point of divergence'
cvs checkout BRANCH
hg addremove --similarity 90 # let Mercurial discover any renames
hg commit -m 'committing branch head'
hg update -r 0               # jump back to point of divergence
cvs checkout HEAD
hg addremove --similarity 90 # let Mercurial discover any renames
hg commit -m 'commiting HEAD head'
hg merge

then the common ancestor for the two heads will be the point of divergence (sorry if the CVS commands are wrong, it's been a mercifully long time).

The trouble is knowing where the POINT_OF_DIVERGENCE is in the CVS repo -- CVS doesn't keep track of that at all, which is why its own merge doesn't use it.

CVS best practices always suggest that whenever you branch you create a tag that marks the point of divergence, but if you didn't do that then there's some tricky hunting ahead of you.

Without a correct most recent common ancestor the Mercurial merge won't be any better than CVS's.

爱给你人给你 2024-10-14 12:55:25

是的,这应该可行,但在此过程中可能会出现一些小问题(例如如何将源代码从 CVS 获取到 Mercurial:使用 hg Convert 或手动导入某个修订版本等)。

如果遇到问题,请创建一个新问题。

Yes, that should work but there might be tiny little problems along the way (like how to get the source from CVS into Mercurial: Using hg convert or doing a manual import of a certain revision, etc).

Please create a new question if you run into a problem.

末蓝 2024-10-14 12:55:25

除了非常简单的历史记录之外,内置的转换扩展不能很好地与 CVS 配合使用。使用 cvs2svn 的分支 cvs2hg

http://hg.gerg.ca/cvs2svn

The built-in convert extension won't do well with CVS except for very simple histories. Use the fork of cvs2svn called cvs2hg

http://hg.gerg.ca/cvs2svn

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文