增加Mercurial代码库相关的功能函数

[linuxbckp]

1.增加同步Mercurial代码库的先决条件函数：init_git_remote_hg()，用于初始化依赖脚本、更新git设置等。此函数只需调用一次即可，无需每次同步Mercurial代码库都调用。 2.增加repo_init()函数的Mercurial适用版本：repo_init_hg() 3.增加update_repo_git()函数的Mercurial适用版本：update_repo_git_hg() 4.由于Mercurial支持MultipleHeads，所以出于防止歧义的考虑，我没法实现checkout_repo()函数的Mercurial适用版本。MultipleHeads的链接详见：https://www.mercurial-scm.org/wiki/MultipleHeads

[taoky]

镜像站直接以静态文件 serve hg clone 出的 .hg 会有什么问题呢？

[linuxbckp]

镜像站直接以静态文件 serve hg clone 出的 .hg 会有什么问题呢？

直接hg clone的效果，类似于git clone不加--mirror一样

[linuxbckp]

镜像站直接以静态文件 serve hg clone 出的 .hg 会有什么问题呢？

另外，如果每次都更换.hg文件然后hg clone，那我没见过这么搞的。对于目前的Git镜像源，难道服务器也是每次都要把.git文件换了吗？显然不是这样

[taoky]

镜像站直接以静态文件 serve hg clone 出的 .hg 会有什么问题呢？

另外，如果每次都更换.hg文件然后hg clone，那我没见过这么搞的。对于目前的Git镜像源，难道服务器也是每次都要把.git文件换了吗？显然不是这样

当然不可能，只在第一次同步的时候 hg clone，之后都 hg pull。但是引入一个奇怪的脚本，然后用 git 去同步 hg 仓库感觉太奇怪了，难道 hg 没有原生的等效于 git clone --bare（或者 git clone --mirror）的实现？我之前测试过在一台机器上 hg clone，然后另一台机器 HTTP 从该机 hg clone 也没有问题。

而且在服务端（用 git smart protocol）服务 git 仓库是需要启动额外的程序的，如果能直接以静态文件服务，可以节省相关的开销。

[linuxbckp]

镜像站直接以静态文件 serve hg clone 出的 .hg 会有什么问题呢？

另外，如果每次都更换.hg文件然后hg clone，那我没见过这么搞的。对于目前的Git镜像源，难道服务器也是每次都要把.git文件换了吗？显然不是这样

当然不可能，只在第一次同步的时候 hg clone，之后都 hg pull。但是引入一个奇怪的脚本，然后用 git 去同步 hg 仓库感觉太奇怪了，难道 hg 没有原生的等效于 git clone --bare（或者 git clone --mirror）的实现？我之前测试过在一台机器上 hg clone，然后另一台机器 HTTP 从该机 hg clone 也没有问题。

而且在服务端（用 git smart protocol）服务 git 仓库是需要启动额外的程序的，如果能直接以静态文件服务，可以节省相关的开销。

很遗憾。hg官方确实没有这种实现 另外，网上有人曝出过hg clone和源代码库产生冲突的问题。宁可信其有，不可信其无。 所以还是谨慎为妙，虽然用了git多点开销，但换来的是已经被验证过的解决方案，这肯定是一个好的选择。

[ZenithalHourlyRate]

所以还是谨慎为妙，虽然用了git多点开销，但换来的是已经被验证过的解决方案，这肯定是一个好的选择。

以 git 方式服务 hg 软件源并不是「镜像」，用户并不能获得和上游一致的工具体验，我们也不知道转换成 git 后用户是否能正常利用该镜像。

建议直接使用 hg 同步相关文件，并将其放在单独的脚本中。

另外可以参考 https://github.com/ustclug/mirrorrequest/issues/251#issuecomment-715888689

[linuxbckp]

• 以 git 方式服务 hg 软件源并不是「镜像」，用户并不能获得和上游一致的工具体验，我们也不知道转换成 git 后用户是否能正常利用该镜像。 首先，这个脚本是经过验证的脚本，具有可靠性。另外，开源社区确实是把这种方式称为“镜像”，虽然这也许和学术上的概念不一致，但不能因此否认它是“镜像”。

• 您可以向 hg 提出相关 patch。 我会征求Mercurial团队的意见。 另外，Git作为一种较新的技术，其功能可能不能和Mercurial完全对应。我也会和Mercurial团队讨论是否真的有必要支持hg clone --mirror这种命令。 我认可你的想法，因为直接hg clone肯定是最方便的。

Zenithal @.***> 于2022年5月11日周三 14:18写道：

所以还是谨慎为妙，虽然用了git多点开销，但换来的是已经被验证过的解决方案，这肯定是一个好的选择。

以 git 方式服务 hg 软件源并不是「镜像」，用户并不能获得和上游一致的工具体验，我们也不知道转换成 git 后用户是否能正常利用该镜像。

建议直接使用 hg 同步相关文件，并将其放在单独的脚本中。

很遗憾。hg官方确实没有这种实现

您可以向 hg 提出相关 patch。

另外可以参考 ustclug/mirrorrequest#251 (comment) https://github.com/ustclug/mirrorrequest/issues/251#issuecomment-715888689

— Reply to this email directly, view it on GitHub https://github.com/tuna/tunasync-scripts/pull/139#issuecomment-1123229759, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOOM5WGIXG6GN5MHIJ26IELVJNGK3ANCNFSM5VSHTMUQ . You are receiving this because you authored the thread.Message ID: @.***>

[linuxbckp]

您可以通过https://bz.mercurial-scm.org/show_bug.cgi?id=6702来跟踪Mercurial团队的意见

Linux BCKP @.***> 于2022年5月11日周三 15:39写道：

• 以 git 方式服务 hg 软件源并不是「镜像」，用户并不能获得和上游一致的工具体验，我们也不知道转换成 git 后用户是否能正常利用该镜像。 首先，这个脚本是经过验证的脚本，具有可靠性。另外，开源社区确实是把这种方式称为“镜像”，虽然这也许和学术上的概念不一致，但不能因此否认它是“镜像”。

• 您可以向 hg 提出相关 patch。 我会征求Mercurial团队的意见。 另外，Git作为一种较新的技术，其功能可能不能和Mercurial完全对应。我也会和Mercurial团队讨论是否真的有必要支持hg clone --mirror这种命令。 我认可你的想法，因为直接hg clone肯定是最方便的。

Zenithal @.***> 于2022年5月11日周三 14:18写道：

所以还是谨慎为妙，虽然用了git多点开销，但换来的是已经被验证过的解决方案，这肯定是一个好的选择。

以 git 方式服务 hg 软件源并不是「镜像」，用户并不能获得和上游一致的工具体验，我们也不知道转换成 git 后用户是否能正常利用该镜像。

建议直接使用 hg 同步相关文件，并将其放在单独的脚本中。

很遗憾。hg官方确实没有这种实现

您可以向 hg 提出相关 patch。

另外可以参考 ustclug/mirrorrequest#251 (comment) https://github.com/ustclug/mirrorrequest/issues/251#issuecomment-715888689

— Reply to this email directly, view it on GitHub https://github.com/tuna/tunasync-scripts/pull/139#issuecomment-1123229759, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOOM5WGIXG6GN5MHIJ26IELVJNGK3ANCNFSM5VSHTMUQ . You are receiving this because you authored the thread.Message ID: @.***>