Perl 和 Ruby 模块位于同一个存储库中？
我已经开始开发一个新的 Perl 模块，并且我决定也想制作它的 Ruby 版本（一旦我完成了 Perl 版本）。人们是否倾向于为每种语言创建单独的存储库？或者将它们放在同一个存储库中？
我可以很容易地看出这两套代码有何不同，足以被视为单独的项目。但同时它是用两种语言编写的相同功能，因此从这个角度来看，它似乎是具有两种语言端口的单个项目。
在这种情况下什么是最佳实践？
FWIW，我正在使用 git。
编辑：我应该在这里说得更清楚。这些不是 git 子模块意义上的模块。它们是将提交给 CPAN 和 RubyGems 的模块。该项目的用户可能会通过 cpan 或 gem 安装它，然后以正常方式使用/需要它。
I've started working on a new Perl module and I've decided that I want to make a Ruby version of it as well (once I finish the Perl version). Do people tend to make separate repositories for each language? Or put them in the same repository?
I can easily see how the two sets of code are different enough to be treated as separate projects. But at the same time it's the same functionality written in two languages, so from that perspective it seems like a single project with two language ports.
What's considered best practice in this situation?
FWIW, I'm using git.
EDIT: I should be more clear here. These aren't modules in the sense of git submodules. They're modules that will be submitted to CPAN and RubyGems. Users of this project will likely be installing it via cpan or gem and then using/requiring it in the normal fashion.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在我的团队的研究过程中，我们有几个存储库，其中一些存储库各自具有不同的技术。我们按研究问题划分存储库，并仅签出我们正在处理的项目，存储库具有对所有项目都相同的统一层次目录结构。由于我们已经知道 repo 目录结构，因此运行脚本和查找数据变得更加容易。
我建议采取相同的方法。两种技术之间的分工越高，就越容易为其中一种技术做出贡献，而不会因另一种技术的存在而感到困惑。
最后问问自己：如果我要添加另一种语言，我还会将其保留在一个存储库中吗？如果答案是肯定的，请继续做你正在做的事情。如果没有，请将这些库保存在两个单独的存储库中，并明确管理项目和贡献者。
In the course of my group's research, we have a couple repos, some with different technologies in each. We divide the repos by research question and checkout only the projects we are working on, with the repos having a uniform hierarchal directory structure that is the same for all projects. Since we already know the repo directory structural, running scripts and finding data becomes much easier.
I would recommend taking the same approach. The higher the division between the two technologies, the easier it will be to contribute to one of them without being confused by the presence of the other.
In the end ask yourself this: If I were to add another language, would I still keep it in one repo? If the answer is yes, keep doing what you're doing. If not, keep these libraries in two separate repos and manage the projects and contributers distinctly.
我在这种情况下的经验是为每个模块都有 2 个较小的 git 存储库，并且将一个分支克隆到消费者项目存储库中使其变得非常简单。另一种方法是从模块的存储库创建一个裸克隆到消费者项目存储库中，然后随着每个模块的开发进度不断更新它。消费者项目应该忽略注入的回购协议。
一旦其他开发人员克隆了模块 A 和/或 B，那么他/她就可以在权限允许的情况下推送到消费者项目。这是有利还是不利取决于。
my experience in this kind of case is to have 2 smaller git repos for each of the modules and either cloning one branch into the consumer projects repo makes it quite simple. another way is to create a naked clone from the module's repo into the consumer projects repo, then just keep updating it as each module's development progresses. the consumer project should ignore the injected repos.
once other dev clones module A, and/or B, then he/she can just push to consumer project, as permissions allow. this is either a pro or a con depends.