Mercurial 共享扩展:如何取消共享?

发布于 2024-09-14 08:54:05 字数 428 浏览 3 评论 0原文

我在 Windows(XP 32 位)上使用 TortoiseHG 1.1.1 附带的 Mercurial 1.6.4 中的 Mercurial 共享扩展。

更多信息请访问: https://www.mercurial-scm.org/wiki/ShareExtension

我已经一直在使用共享扩展,在两个方向上都效果很好。 主存储库位于本地硬盘上,共享存储库位于网络共享上(AIX 上的 Samba)。

现在我想删除一个共享链接(双方都必须知道该链接,因为它们会互相更新)。我该怎么做?我在网上找不到任何东西……“分享”、“取消分享”这些词不太适合谷歌搜索。

感谢任何帮助,亲切的问候,Tijs

I'm using the Mercurial share extention in the Mercurial 1.6.4 supplied with TortoiseHG 1.1.1 on Windows (XP 32 bit).

More info at:
https://www.mercurial-scm.org/wiki/ShareExtension

I've been using the share extention, works nice, in both directions.
The main repo is on a local harddisk, the shared repo is on a network share (Samba on AIX).

Now I want to remove a share link (which must be known on both sides, since they update eachother). How do I do that? I can't find anything on the web... the words "share" , "unshare", aren't very googlable.

Any help appreciated, kind regards, Tijs

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

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

发布评论

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

评论(1

旧人九事 2024-09-21 08:54:05

我认为您误解了该扩展。 (很少使用!)共享扩展适用于当您希望多个工作目录指向同一个底层存储库时,而不是存储库和工作目录之间更正常的一对一关系。

由于没有双向链接,因此无法取消共享。

解释如下:

您使用 hg inithg clone 创建一个新的存储库:

repoA
\-- .hg (repoA's repository)

如果您创建了另一个克隆,您将拥有另一个工作目录,其中包含另一个存储库。 99.9% 的情况都是这样做的。

repoA  (the one you already had)
\-- .hg (repoA's repository)

repoB  (the new clone)
\-- .hg (repo B's repository)
    \-- hgrc (config file with a [paths] default=../repoA)

但是,如果您使用 hg share 您会得到类似这样的结果:

repoA  (the one you already had)
\-- .hg (repoA's repository)

repoB  (the new shared repo)
\-- .hg (a symlink-like pointer to ../repoA/.hg)

所以它看起来是双向的,只是因为它们在幕后拥有完全相同的存储库。如果它们位于不同的计算机/卷上,那么如果 repoA 不可用,则 repoB 就无法使用 - 这与 DVC 应该为您做的事情相反。

因此,在回答中,您可以通过删除 repoB 来“取消链接”。如果 repoB 中有未提交的文件,您不想提交到 repoA 中,您可以执行以下操作:

hg clone -U repoA newRepoB  # create a clone with no working dir
cp -a repoB/* newRepoB    # excludes all files including .hg (and other .* files)

TL;DR: don't use share ;这几乎从来都不是正确的选择。

I think you are/were misunderstanding that extension. The (very seldom used!) share extension is for when you want multiple working dirs pointing to the same underlying repository -- instead of the much more normal one to one relationship between repos and working dirs.

There's no unshare because there's no bi-directional link.

Here's an explanation:

You create a new repo using hg init or hg clone:

repoA
\-- .hg (repoA's repository)

If you created another clone you'd have another working directory with another repository inside it. This is what's done 99.9% of the time.

repoA  (the one you already had)
\-- .hg (repoA's repository)

repoB  (the new clone)
\-- .hg (repo B's repository)
    \-- hgrc (config file with a [paths] default=../repoA)

However, if you use hg share you'll get something like this:

repoA  (the one you already had)
\-- .hg (repoA's repository)

repoB  (the new shared repo)
\-- .hg (a symlink-like pointer to ../repoA/.hg)

So it appears bidirectional only because they have the exact same repo under the covers. If they're on different machines/volumes then repoB is unusable if repoA isn't available -- which is the opposite of what a DVCs is supposed to do for you.

So, in answer you "unlink" by deleting repoB. If there are uncommitted files in repoB that you don't want to commit into repoA you can do something like this:

hg clone -U repoA newRepoB  # create a clone with no working dir
cp -a repoB/* newRepoB    # excludes all files including .hg (and other .* files)

TL;DR: don't use share ; it is almost never the right choice.

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