在单独的 git 存储库中维护/测试（主要是 Perl）软件以及它们之间的依赖关系的最佳实践是什么？
我正在致力于重构一个大型（主要是 Perl）代码库。我不想将所有内容放入一个巨大的 git 存储库中，而是希望将相关模块及其测试分组到单独的 git 存储库中，并使存储库的结构类似于 CPAN 发行版。
一个问题是，如果每个存储库都有一个不同的 CPAN 分发树，那么使用子模块似乎很尴尬，因为（出于测试目的）我们真正想要的是在测试中包含每个子模块的“lib”。这是一个小问题，我已经知道各种简单的解决方法（在测试中“使用 lib...”），但我想知道其他开发人员在类似情况下会做什么，以及什么被认为是最佳实践。
更重要的问题是如何处理分支。如果创建了子模块的新分支，然后更新了该分支，我如何测试该分支依赖于它的超级存储库中的代码？ （我可能不一定要对超级存储库进行更改，只需检查对子模块的更改是否不会破坏任何内容。）
类似地，是否有实用程序可以跟踪 git 存储库之间的依赖关系，以便我可以确定更改依赖项后哪些超级存储库需要测试分支？
I am working on refactoring a large (mostly Perl) codebase. Rather that put everything into one giant git repository, I'd like to group related modules and their tests into separate git repositories, and to have the repositories structured like CPAN distributions.
One problem is that if each repository has a distinct CPAN distribution tree, then it seems awkward to use submodules, since (for testing purposes) what we really want is to include each submodule's "lib" in the tests. This is a minor issue, and I am already aware of various easy workarounds ("use lib..." in tests), but I would like to know what other developers do in similar situations, and what are considered best practices.
A more important issue is how to deal with branching. If a new branch of the submodule is created, and then the branch is updated, how can I test the code in the super-repositories that depend on it for that branch? (I may not necessarily want to make changes to the super-repositories, just check that changes to the submodule didn't break anything.)
On a similar note, are there utilities that can track dependencies between git repositories, so that I can determine which super-repositories need testing for a branch after changes to a dependency?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
由于该软件已经支持 CPAN，只需在以下位置声明测试依赖：发行版元文件。换句话说，从发行版角度思考，而不是存储库/分支。我认为你缺少像 CPAN::Mini 或 DPAN 这样的东西，以及打包和注入发行版的过程。
分支应该增加版本号，可能使用下划线数字或使用
-TRIAL发行版名称来指示不稳定版本。As the software is already CPAN-ready, simply declare the test deps in the distro meta file. In other words, think in terms of distributions, not repositories/branches. I think you're lacking something like CPAN::Mini or DPAN, and a process of packaging and injecting the distros.
A branch should increase the version number, possibly using an underscore number or using the
-TRIALdistro name to indicate a non-stable release.PERL5LIB 环境变量可用于避免向脚本添加临时
use lib语句。 perlrunThe
PERL5LIBenvironment variable could be used to avoid adding temporaryuse libstatements to your scripts. perlrun