Subversion 中的 Mercurial:移动、重命名和标签

发布于 2024-08-03 02:15:17 字数 757 浏览 10 评论 0原文

我有一个具有以下布局的 subversion 存储库:

svnrepo/projectA/trunk
svnrepo/projectA/tags
svnrepo/projectA/branches
svnrepo/projectB/trunk
svnrepo/projectB/tags
svnrepo/projectB/branches


我想将其转移到具有修改后布局的 Mercurial 存储库:
hgrepo/projectA
hgrepo/projectB

执行此操作的最佳方法是什么?我的一些想法是:

选项1

将 subversion 中的路径(使用 svn move)重新排列为中间格式:

svnrepo/trunk/projectA
svnrepo/trunk/projectB
svnrepo/tags/projectA
svnrepo/tags/projectB
svnrepo/branches/projectA
svnrepo/branches/projectB

然后在 svnrepo/trunk 上进行 hg 转换。这会混淆 hg 导入吗?

选项 2 hg 将每个项目/主干转换为单独的 hg 存储库。然后将它们合并到一个 hg repo 中(使用 hg init、hg pull -f projectA 等)。我认为这将丢失第一个导入项目的分支名称和标签。

I have a subversion repo with the following layout:

svnrepo/projectA/trunk
svnrepo/projectA/tags
svnrepo/projectA/branches
svnrepo/projectB/trunk
svnrepo/projectB/tags
svnrepo/projectB/branches

which I would like to move to a mercurial repo with a revised layout:
hgrepo/projectA
hgrepo/projectB

What is the best way of doing this? Some of my thoughts are:

Option1

Rearrange the paths in subversion (using svn move) to an intermediate format:

svnrepo/trunk/projectA
svnrepo/trunk/projectB
svnrepo/tags/projectA
svnrepo/tags/projectB
svnrepo/branches/projectA
svnrepo/branches/projectB

then hg convert on the svnrepo/trunk. Will this confuse hg importing?

Option 2
hg convert each of the projects/trunk into separate hg repos. Then merge them into a single hg repo (using hg init, hg pull -f projectA, etc). I think this will lose the branch names and tags on the first imported project.

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

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

发布评论

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

评论(2

玉环 2024-08-10 02:15:17

在 Mercurial 中,将不相关的代码库存储在同一个存储库中是一个坏主意,因为它会使

  • 合并变得非常复杂。合并将取决于对所有项目所做的更改,而不仅仅是您尝试合并的项目。
  • 导致存储和签出开销——据我所知,Mercurial 不支持仅签出存储库的子目录。您必须立即对所有项目进行分支。

解决方案是将单个 Subversion 存储库转换为多个 Mercurial 存储库。大多数转换工具都支持这一点。

In Mercurial, storing unrelated codebases in the same repository is a bad idea because it will

  • Significantly complicate merging. Merges will depend on changes made to all projects, rather than just the project you're trying to merge.
  • Cause storage and checkout overhead -- Mercurial, as far as I know, does not support checking out only subdirectories of a repository. You'd have to branch all projects at once.

The solution is to convert your single Subversion repository into multiple Mercurial repositories. Most conversion tools support this.

烟柳画桥 2024-08-10 02:15:17

每个项目都应该位于自己的 Hg 存储库中(以便能够仅获取或标记特定项目)。

请记住,您在 Subversion 中看到的目录(主干、标签、分支)不会存在于任何现代 (D)VCS 中,其中分支和标签是一等公民(即由工具直接管理的元数据),而不是简单的由廉价副本生成的目录(在 SVN 中)。

这意味着当您转换 SVN 存储库时,不应在 Hg 存储库的历史记录中直接存储任何“trunk”、“tags”或“branches”目录。

您应该使用工具,例如hgsubversion 将您的 SVN 存储库(如“repo/projectA”)导入到专用于 projectA 的 Hg 存储库中。它将保留原始 SVN 项目的标签和分支,并将它们转换为 Hg 对象。
来自
其文档

使用 hgpullsvn 进行的所有更新均在以 SVN URL 最后一个部分命名的分支中进行(例如,如果 SVN URL 为 svn://server/myproj/branches/feature -ZZZhgpullsvn 将创建并使用命名分支“feature-ZZZ”)


如果您不想“转换”而是“同步”,tonfa推荐 hgsubversion,尽管它“目前由于大量重构而处于不断变化的状态”:

目前它还没有准备好用于生产。只有当您准备好破解它并深入研究 Mercurial 和/或 Subversion 的内部结构时,才应该使用它。

由于 hgsvn 还允许通过 hgpushsvn 和 hgpullsvn 进行一些同步...我现在会坚持使用 hgsvn 。

Each project should be in its own Hg repository (to be able to get or tag only a specific project).

Remember than the directory you see in Subversion (trunk, tags, branches) will not exist in any modern (D)VCS, where branches and tags are first class citizen (i.e. meta-data directly managed by the tool), as opposed as simple directory resulting from a cheap copy (in SVN).

That means when you convert a SVN repository, you should not store directly any "trunk", "tags" or "branches" directory in the history of the Hg repo.

You should rather use a tool like hgsubversion to import your SVN repo (like just "repo/projectA") into a Hg repo dedicated to the projectA. it will keep tags and branches of the orignal SVN project and convert them into Hg objects.
From its documentation:

All updates using hgpullsvn are made in the branch named from the last component of the SVN URL (e.g., if the SVN URL is svn://server/myproj/branches/feature-ZZZ, hgpullsvn will create and use the named branch 'feature-ZZZ')


If you do not want "convert" but "syncing", tonfa recommend hgsubversion, although it "is currently in a state of flux due to heavy refactoring":

Right now it is not ready for production use. You should only be using this if you're ready to hack on it, and go diving into the internals of Mercurial and/or Subversion.

Since hgsvn also allow some syncing through hgpushsvn and hgpullsvn... I would stick with hgsvn for now.

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