如何将变更集从 hg 存储库导出到 svn 存储库

发布于 2024-08-13 09:41:50 字数 320 浏览 5 评论 0原文

我知道 Mercurial 有 hgsubversion 扩展。但在我知道它是如何工作之前，我维护了两个独立的存储库，一个是 SVN repo，一个是 Hg repo。我最近在 Hg 存储库中进行了大部分更改，我需要将它们“推送”到 svn 存储库。

最直接的方法是从 svn 获取一个修订版，该修订版与 hg 的一个修订版同步。

从那里，我更新到下一个修订版（来自 Hg），然后提交它（到 svn）。对许多变更集重复这些步骤相当不方便。有更方便的方法来做到这一点吗？

如果可能的话，提供适用于 Windows 操作系统的解决方案。

问候，

非洲

原文

分享到QQ

分享到微博

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

发布评论

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

手长情犹 2024-08-20 09:41:50

如果您正在谈论一系列线性变更集（无合并），您可以使用 shell for 循环，

for therev in $(seq $(hg id -n -r .) $(hg id -n -r tip)) ; do
  hg update $therev
  svn commit -m "$(hg log --template '{desc}' -r .)"
done

该循环从签出修订版循环到提示，并依次提交每个变更集并保留提交消息。您可能需要在添加/删除文件方面做一些奇特的事情。

If you're talking about a linear series of changesets (no merges) you could employ a shell for loop

for therev in $(seq $(hg id -n -r .) $(hg id -n -r tip)) ; do
  hg update $therev
  svn commit -m "$(hg log --template '{desc}' -r .)"
done

That loops from the checkedout revision to the tip and commits each in turn preserving the commit message. You probably need to do something fancy arround added/removes files.

回复收藏 0 原文

疯了 2024-08-20 09:41:50

不，没有。

您可能已经看过此链接。目前尚未正式支持与 svn repos 交互。我不会编写 shell 脚本来自动执行此操作。这可能会产生意想不到的结果，搞乱存储库（但是请查看以下工作流程）

https:// www.mercurial-scm.org/wiki/WorkingWithSubversion。

我目前正在做与你类似的事情。

从 svn repos 签出并将其保存在 $HOME/svnhgrepos/project1 下
转到 $HOME/svnhgrepos/project1，hg init，hg commit
更改 $HOME/svnhgrepos/project1/.hg/hgrc 以在推送时自动更新
将 $HOME/svnhgrepos/project1 克隆到 $HOME/code/project1-clone。
转到 $HOME/code/project1-clone, hg qinit (mercurial 队列)
完成所有开发并提交（每个功能/错误修复只需一个变更集）
并将其推送到 $HOME/svnhgrepos/project1
转到 $HOME/svnhgrepos/project1，然后执行 'svn ci'
我的设置中没有执行此步骤。
现在你可以编写一个 hg hook，来自动执行“hg update”和“svn commit”
<前><代码>
例如（我没有测试过这个）
在 $HOME/svnhgrepos/project1/.hg/hgrc
[挂钩]
changegroup.hg-update = hg更新>&2
changegroup.svn-commit = svn commit -m "hg log --template '{desc}' -r ."

No there are not.

You might have already seen this link. Currently interacting with svn repos is not officially supported yet. I would not write a shell script to automate this. This may yield unexpected results screw up the repos (however take a look at following workflow)

https://www.mercurial-scm.org/wiki/WorkingWithSubversion.

I currently do something similar to what you do.

checkout from svn repos save it under $HOME/svnhgrepos/project1
goto $HOME/svnhgrepos/project1, hg init, hg commit
change $HOME/svnhgrepos/project1/.hg/hgrc to automatically update on push
clone $HOME/svnhgrepos/project1 to $HOME/code/project1-clone.
goto $HOME/code/project1-clone, hg qinit (mercurial queues)
do all the development, commit it (just one changeset per feature/bugfix)
and push it to $HOME/svnhgrepos/project1
Goto $HOME/svnhgrepos/project1, and perform 'svn ci'

I have not done this step in my setup.
Now you may write a hg hook, to automatically peform a 'hg update' and a 'svn commit'


   e.g (i have not tested this)
   in $HOME/svnhgrepos/project1/.hg/hgrc   
   [hooks]
   changegroup.hg-update = hg update >&2
   changegroup.svn-commit = svn commit -m "hg log --template '{desc}' -r ."

回复收藏 0 原文

娇柔作态 2024-08-20 09:41:50

我接受了 Ry4an 的答案并添加了添加/删除处理。就是这样：

for therev in $(seq $(hg id -n -r .) $(hg id -n -r tip)) ; do
  hg update -C $therev
  svn st | perl -lne 'if (/^([?!])\s*(\S*)/) { my $command = ($1 eq "?") ? "add" : "rm"; my $fname=$2; $fname =~ s[\\][\/]g; system(qq(svn $command $fname));}'
  svn commit -m "$(hg log --template '{desc}' -r .)"
done

我发现当涉及分支时需要 -C 。不过，这变得非常难看，因为在分支之间切换时文件会被删除并重新添加。一般来说，重命名信息以及原始提交者的日期和身份都会丢失。

I took Ry4an's answer and added add/remove handling. Here it is:

for therev in $(seq $(hg id -n -r .) $(hg id -n -r tip)) ; do
  hg update -C $therev
  svn st | perl -lne 'if (/^([?!])\s*(\S*)/) { my $command = ($1 eq "?") ? "add" : "rm"; my $fname=$2; $fname =~ s[\\][\/]g; system(qq(svn $command $fname));}'
  svn commit -m "$(hg log --template '{desc}' -r .)"
done

I found the -C was required when branches were involved. This gets pretty ugly, though, since files get removed and re-added when switching between branches. Also generally, renames info is lost, as well as the dates and identity of original commiter, of course.

回复收藏 0 原文

怪异←思 2024-08-20 09:41:50

看起来您可以使用 hg Convert 来追溯执行您想要的操作。启用 ConvertExtension，然后执行 hg Convert -d svn file/path/to/mercurial/repo svn://repo/path/ 虽然我还没有尝试过。

回复收藏 0 原文

过气美图社 2024-08-20 09:41:50

这可能不完全是您想要的，但我认为您可能会在某些时候发现它有用。而且，其他人也可能...

我使用 Windows 7 操作系统，并且使用 Mercurial (TortoiseHg) 和 Subversion (TortoiseSVN) 进行源代码控制。为什么？嗯，我们发现，在我们大约 8 人的小团队中，Mercurial 作为“个人”安全网使用起来非常方便，但对我们的一些人来说却很困惑（例如，在Verilog）。整个“推”和“拉”思维以及将其他人的一整堆变化合并到你的变化中的要求并没有受到张开双臂的欢迎。这似乎很繁琐，在一个案例中，一位工程师由于误解了 Mercurial 做这些事情的一些细微差别而失去了所有的工作。幸运的是，还有另一个副本（她是一位聪明的工程师！），所以一切都没有丢失，但它证明了 Mercurial 的操作可能会令人困惑且难以预测，至少对某些人来说是这样。

Mercurial 的优势（IMO）是您可以轻松地在各种开发分支之间切换，并且使用 TortoiseHg 工具，可视化版本树并选择您想要处理的内容。您可以非常轻松（并且快速！）保存您的工作，抓住另一个分支或开始一个新的分支，做一些实验或寻求替代方法。作为一个方便的个人安全网和分支切换工作台工具，它是一流的。我在开发和测试代码时一直使用它。

另一方面，Subversion 打造了一个非常易于使用的“团队”服务器。人们发现很容易理解它是如何工作的。标记和分支并不那么直观，但我们并不经常这样做。更新、合并和签入似乎更直观且更易于管理。

事实证明，您实际上可以使用 Mercurial 和 Subversion 同时管理单个工作副本！您可以从 SVN 签出，然后使用 Mercurial“在此处创建存储库”，或者反之亦然。您必须编辑 SVN 的忽略设置以忽略工作副本文件夹中的所有 .hgxxxx 文件，并让 Mercurial 忽略 .svn 目录。完成此操作后，任一系统的命令行或 shell 扩展工具将继续像以前一样工作，并且您现在可以在两个不同的存储库中管理代码！

起初我对此表示怀疑，但我确实想要日常 Mercurial 的便利性以及 Subversion 的中央服务器合规性，这也是我们团队为共享代码存储库选择的。这种工作方式可以让你两全其美，而且到目前为止我还没有注意到任何缺点。

This might not be exactly what you want, but I think you might find this of use at some point. And, others may as well...

I work on Windows 7 OS, and I use both Mercurial (TortoiseHg) and Subversion (TortoiseSVN) for source control. Why? Well, what we have found, on our very small team of about 8 people, is that Mercurial is very convenient to use as a "personal" safety net, but is very confusing to some of our folks (eg, the FPGA engineers working in Verilog). The whole "push" and "pull" think with the requirement to merge a whole stack of other people's changes into yours was not welcomed with open arms. It seemed burdensome, and in one case, an engineer lost all of her work due to misunderstanding some of the nuances of how Mercurial does these things. There was fortunately another copy (she's a smart engineer!) so all was not lost, but it demonstrated how Mercurial's operations could be confusing and difficult to predict, at least for some people.

Mercurial's strength (IMO) is the ease with which you can switch between various development branches, and with the TortoiseHg tool, visualize the version tree and pick what you want to work on. You can very easily (and quickly!) save your work, grab another branch or start a new one, to do some experiments or pursue an alternative approach. As a convenient personal safety net and branch-switching workbench tool, it is superb. I use it all the time as I'm developing and testing my code.

Subversion, on the other hand, makes a very easy to use "team" server. People find it easy to understand how it works. Tagging and branching are not as intuitive, but we don't do this very often. Updates, merges, and checkins seem more intuitive and easier to manage.

It turns out, you can actually manage a single working copy using BOTH Mercurial and Subversion -- simultaneously! You can either checkout from SVN, then use Mercurial to "create repository here", or do it the other way around. You have to edit the ignore settings of SVN to ignore all the .hgxxxx files in your working copy folder, and have Mercurial ignore the .svn directory. Once you've done that, the command line or shell extension tools for either system continue to work just as they have, and you are now managing your code in two different repositories!

I was skeptical at first, but I really wanted the convenience of day to day Mercurial, with the central-server compliance of Subversion, which is what our team has chosen for the shared code repository. This way of working gives you the best of both worlds with no downsides that I have noticed so far.

回复收藏 0 原文

~没有更多了~