将 SVN 迁移到 HG,顺便将其拆分为子存储库(但保留组合日志)

发布于 2024-11-02 21:46:41 字数 449 浏览 5 评论 0原文

我有一个 SVN 存储库,其主干中包含许多松散相关的子文件夹。
我想将其转换为 HG 存储库,将每个子文件夹转换为单独的 HG 子存储库。
同时,我想访问顶级存储库中所有子存储库的合并更改日志。

所以我创建了一个空的 HG 存储库,一些空的子存储库,通过 .hgsub 链接它们的名称和位置,检查我是否可以将此存储库与其子存储库一起克隆到另一个组件...

然后我尝试将部分 SVN 克隆到子存储库(指定每个子存储库的 SVN URL 带有 .../trunk/subfolder)。但出于我不知道的原因,他们没有出现在顶级 HG 历史中。

我从头开始,尝试将 SVN trunk URL 放入顶级 .hg/hgrc 并执行“hg pull”。但它将整个 SVN 存储库拉到顶层,子存储库留空。

现在我想问你下一步做什么?
由于我是 HG 的新手,可能我错过了一些东西。 我将不胜感激你的任何建议。

I have an SVN repository which contains a number of loosely-related subfolders in its trunk.
I would like to convert it into HG repository, turning each of these subfolders into a separate HG subrepo.
At the same time, I would like to access combined change log of all subrepos in the top level repo.

So I created an empty HG repo, some empty subrepos, linked their names and locations by .hgsub , checked that I can clone this repo together wth its subrepos to another comp ...

Then I tried to make partial SVN clones to subrepos (specifying SVN URL with .../trunk/subfolder for each subrepo). But they did not show in top-level HG history for a reason unknown to me.

I started from scratch, and tried to put SVN trunk URL into top-level .hg/hgrc and to do 'hg pull'. But it pulled the whole SVN repo into top level, and subrepos were left empty.

And now I would ask you what do to next ?
Probably I am missing something since I am new to HG.
I would appreciate any your advise.

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

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

发布评论

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

评论(1

丿*梦醉红颜 2024-11-09 21:46:41

当涉及到 Hg 子存储库时,报告修订历史记录和单个文件状态会变得有点复杂。

修订历史记录

子存储库的修订历史记录在父存储库中不可见。当您考虑时,这是有道理的,因为每个子存储库实际上都是一个不同的存储库 - 确实没有好方法来覆盖两个单独的历史记录,这些信息也不是非常有用。您必须从命令行导航到每个子存储库目录并执行 hg log 才能查看历史记录。从 TortoiseHg 2.XX 开始,从提交视图,您可以双击任何标有 S 的内容以在 TortoiseHg GUI 中打开该子存储库。

本地修改

对子存储库的本地修​​改可以从父存储库中看到,但每个命令的方式不一定相同。例如,如果我有一个如下所示的存储库(其中 sub 是子存储库):

/project
  |
  ----> foo.c
  |
  ----> sub/
         |
         ----> bar.c
         |
         ----> more.c

如果我修改 bar.c 和 foo.c,然后执行 hg status 从命令行我将看到以下内容:

> hg status
M    foo.c

但是如果我添加 subrepo 参数 -S 我会看到:

> hg status -S
M    foo.c
M    sub/bar.c

如果我使用 TortoiseHg v2.XX 它会将 foo.c 标记为已修改,并且它将将 sub 标记为已修改,但我必须双击子存储库才能查看实际的文件修改。

转换说明:

关于执行转换本身 - 查看转换存储库 扩展名。如果您正在执行一次性转换,然后放弃 SVN 存储库,这可能就是您所需要的。如果您打算尝试在 SVN 和 HG 之间来回工作,您可能还会遇到更多问题。

我过去成功完成的事情是将 Hg 存储库覆盖在现有存储库之上。不过,我不确定这是否适用于 SVN 和 Hg。

Reporting revision history and individual file statuses get a little bit complex when it comes to Hg subrepos.

Revision history

The revision history of a subrepo is not visible from the parent repository. This makes sense when you think about it because each subrepo is literally a different repository - there is really no good way to overlay two separate histories, nor would that information be very useful. From the command line you would have to navigate into each subrepo directory and execute a hg log to see the history. From TortoiseHg 2.X.X, from the commit view, you can double click on anything marked with an S to open up that subrepo in the TortoiseHg GUI.

Local modifications

Local modifications to subrepos can be seen from the parent repo, but not necessarily in the same way for each command. For example, if I have a repository that looks like this (where sub is a subrepo):

/project
  |
  ----> foo.c
  |
  ----> sub/
         |
         ----> bar.c
         |
         ----> more.c

If I modify both bar.c and foo.c and then perform an hg status from the command line I will see the following:

> hg status
M    foo.c

But if I add the subrepo argument -S I would see:

> hg status -S
M    foo.c
M    sub/bar.c

If I am using TortoiseHg v2.X.X it will mark foo.c as modified and it will mark sub as modified, but I would have to double click the subrepo to view the actual file modifications.

Conversion notes:

In terms of performing the conversion itself - check out the convert repository extension. If you are performing a one time conversion and then abandoning the SVN repository this would probably be all you need. If you're going to try and work back and forth between SVN and HG you will probably have a few more issues.

Something I've done successfully in the past is overlay a Hg repository on top of an existing repository. I'm not sure if this would work well for SVN and Hg, however.

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