是否可以使用 Mercurial 从 SourceGear Vault 存储库中拉取/推送到该存储库?

发布于 2024-09-08 17:51:06 字数 64 浏览 2 评论 0原文

我注意到这种功能是为了颠覆而存在的,而且效果非常好。我想知道 SourceGear Vault 是否有这样的东西。

I noticed that this kind of functionality exists for subversion and it works very nicely. I was wondering if there is such thing for SourceGear Vault.

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

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

发布评论

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

评论(1

独守阴晴ぅ圆缺 2024-09-15 17:51:06

不,恐怕我们只有用于 SubversionGit。我还没有听说有人为 SourceGear Vault 编写桥梁。

但是,您仍然可以在其他系统之上使用 Mercurial。这是适用于所有版本控制系统 (VCS) 的通用技术。您要做的如下:

从国外版本控制系统中检查最新版本的代码。初始化 Mercurial 存储库,添加所有文件并进行提交:

# checkout foreign VCS
$ hg init
$ hg addremove
$ hg commit

工作副本现在既是 Mercurial 工作副本,又是外部系统的工作副本。您将在 Mercurial 中进行开发并定期将其导入到外部系统中,并且您将定期将更改从外部 VCS 导入到 Mercurial 中。

我们将使用名为 default 的分支来跟踪外部系统的历史记录,并使用名为 hg 的命名分支来跟踪我们在 Mercurial 中所做的开发。

注意: Anton 在下面评论说,如果您使用命名分支来分隔两条开发线,Vault 将显示太多文件 - 如果这对您来说是一个问题,请使用两个克隆。

让我们创建 hg 分支:

$ hg branch hg
$ hg commit -m "Started hg branch"

您现在可以开发一些东西:

# work, work, work...
$ hg commit -m 'Fixed bug 42'
# work, hack, work...
$ hg commit -m 'Customers will love this feature!'

当您像这样工作时,default 分支将开始与 hg 分叉>分支——区别正是尚未导出到外部系统的更改。 差异

$ hg diff default:hg

您可以看到与要实际导出更改,您更新到 default 分支,将 hg 合并到其中并将更改提交到外部系统的

$ hg update default
$ hg merge hg
$ hg commit -m 'Merge with hg'
# get list of renamed files:
$ hg status --added --copies --change . | grep -A 1 '^ '
# commit to foreign VCS

:然后您可以更新返回到 hg 分支并继续使用 Mercurial

$ hg update hg
# work, work, wok...

当其他人在外部 VCS 中进行更改时,您必须将它们合并回您的 hg 分支。您首先更新到 default 分支。这可以确保工作副本看起来像外部 VCS 期望的那样。然后,您可以更新工作副本——这使 Mercurial 看到您提交给 Mercurial 的更改:

$ hg update default
# update working copy using foreign VCS
$ hg addremove --similarity 90
$ hg commit -m 'Imported changes from foreign VCS'

hg addremove 步骤确保 Mercurial 拾取外部 VCS 中发生的任何重命名。您需要尝试相似性参数以找到适合您的设置。使用 hg status -C 查看计划的重命名。

您现在需要将这些更改合并回 hg 分支,以便您可以将它们合并到您进一步的基于 Mercurial 的工作中:

$ hg update hg
$ hg merge default
$ hg commit -m 'Merge with default'

您继续像这样工作 - 始终在 上进行新的本地开发hg 分支,并在使用外部 VCS 命令(更新、提交等)之前始终更新到 default 分支。

我希望本指南可以帮助您或其他人! :-)

Nope, I'm afraid we only have two-way bridges for Subversion and Git. I have not heard of anyone writing a bridge for SourceGear Vault.

However, you can still use Mercurial on top of the other system. This is a general technique that works for all version control systems (VCSs). What you do is the following:

Checkout the latest version of the code from your foreign version control system. Initialize a Mercurial repository, add all files, and make a commit:

# checkout foreign VCS
$ hg init
$ hg addremove
$ hg commit

The working copy is now both a Mercurial working copy as well as a working copy for the foreign system. You will be doing development in Mercurial and periodically import it into the foreign system, and you will periodically import changes from the foreign VCS into Mercurial.

We will use the branch called default to track the history of the foreign system, and a named branch called hg to track the development we do in Mercurial.

Note: Anton comments below that Vault will show too many files if you use named branches to separate the two lines of development — use two clones instead if this is a problem for you.

Let us make the hg branch:

$ hg branch hg
$ hg commit -m "Started hg branch"

You can now develop something:

# work, work, work...
$ hg commit -m 'Fixed bug 42'
# work, hack, work...
$ hg commit -m 'Customers will love this feature!'

As you work along like this, the default branch will begin to diverge from the hg branch -- the difference is exactly the changes that have yet to be exported to the foreign system. You can see the differences with

$ hg diff default:hg

To actually export the changes, you update to the default branch, merge hg into it and commit the change to your foreign system:

$ hg update default
$ hg merge hg
$ hg commit -m 'Merge with hg'
# get list of renamed files:
$ hg status --added --copies --change . | grep -A 1 '^ '
# commit to foreign VCS

You can then update back to the hg branch and continue working with Mercurial

$ hg update hg
# work, work, wok...

When changes are made by others in the foreign VCS, you have to merge them back into your hg branch. You first update to the default branch. This ensures that the working copy looks how the foreign VCS expects it to look like. You can then update the working copy -- this makes Mercurial see changes, which you commit to Mercurial:

$ hg update default
# update working copy using foreign VCS
$ hg addremove --similarity 90
$ hg commit -m 'Imported changes from foreign VCS'

The hg addremove step makes sure that Mercurial picks up any renames that has taken place in the foreign VCS. You will need to experiment with the similarity parameter to find a setting that suits you. Use hg status -C to see the scheduled renames.

You now need to merge these changes back into the hg branch so that you can incorporate them in your further Mercurial-based work:

$ hg update hg
$ hg merge default
$ hg commit -m 'Merge with default'

You continue working like this -- always making new local development on the hg branch, and always updating to the default branch before you use the foreign VCS commands (update, commit, etc).

I hope this guide can help you or someone else! :-)

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