Mercurial 在回购协议中共享一个通用脚本

我的团队的源代码管理的目录结构涉及许多连接到大型第三方应用程序的定制repo。它们包含的脚本只需存在于该应用程序内的特定文件夹中即可运行。目前，当开发人员在项目/回购之间切换时，他们会将其目录复制并粘贴到此回购中，并删除其他回购（或将其移动到单独的“非活动”目录）。这（显然）偶尔会导致文件丢失，或者repo开关之间的目录没有被正确“清理”的问题

为了想出一种更简单的方法来处理这个问题，我编写了一个脚本，它将创建一个从repo到第三方应用程序“scripts”文件夹的符号链接，并删除以前在那里创建的其他符号链接。这将创建一个更新+运行脚本的两步过程（尽管将来我可能会将此脚本直接挂接到mercurial中，使切换repos成为一个命令）

第一个问题：这个符号链接系统有意义吗，或者有更好的方法吗

第二个问题：我应该如何在回购协议之间有效地共享此文件？我的第一个想法是使用子回购协议，但对于一个简单的脚本来说，这似乎有些过分，需要手动将其包含在每个回购协议中

---

请注意：单一单一单一回购协议并不是一个真正的选项，因为我不想在系统中创造太多的搅动来实现这一点。此外，我们目前确实有一个核心库，它是我们定制repo中的子repo，如果这有区别的话。我曾考虑将其存储在核心回购协议中，但我无法保证脚本从任何一个回购协议的内部运行。

有几个选项，但每个选项都有回退：

• 您可以使所有项目成为包含用于构建项目的脚本和帮助文件的项目的子repo

• 您确实可以将脚本repo作为每个项目的子repo

• 您可以简单地将脚本repo拉入每个项目，并将其与项目合并。Mercurial会警告你这是无关的，但肯定是，你希望知道自己在做什么。如果执行此操作，则需要确保脚本repo具有文件夹结构，以便它与您的所有项目兼容，从而可以轻松地进行合并。如果脚本repo经历更新，只需再次拉入并与项目的开发树合并即可

---

sub-repo方法具有回溯功能，即您开始使用sub-repo，它在工作流中具有粗糙的边缘。因此，我建议拉合并。它给了你一点重复（因为它存在于每个回购协议中），唉，它只是一个脚本。

当你说子模块时，你说的是a，对吗？是的，我错了。我来自Git背景，这两个术语混淆了。我将更新它，并且永远不会合并回脚本。因此，也许有一个值得警惕的问题是，我们目前有太多的回购协议是为了我们自己的利益（我们正在努力减少回购协议，但目前仍有几十个）。这个脚本目前相当简单，但我们期望它将开始为我们处理更多的构建案例，我希望能够轻松地更新它，而无需合并到每个repo中。考虑到这一点，第一种或第二种情况似乎最有意义，但我同意它仍然会产生一个粗略的工作流程。也许可以使用一种混合方法：将（通用）脚本保存在单独的repo中。并且只在每个项目的repo中存储一个配置文件，该配置文件由脚本读取，该脚本告诉它需要知道什么（项目类型，可能是一些路径或工具配置或其他）。在我的CI（jenkins）服务器上，我在一个单独的项目中有一个构建脚本和一些工具。“真实”项目有一个特定于项目的配置文件，它告诉构建脚本如何处理项目（有不同的项目类型）。因此，构建脚本获得一个路径，并从中读取配置文件，其他所有内容都从该路径开始。