我在一家小商店工作，那里有很多遗留的 Cobol 代码，并且采用了一种方法来让我们尽可能减少分叉和分支。
对于给定的版本，我们有三个级别：
- CORE - 底层，此代码对所有版本通用
- GROUP - 多个客户共有的可选代码。
- 客户 - 特定于单个客户的可选代码。
当需要某个程序时，首先在 CUSTOMER 中搜索，然后在 GROUP 中搜索，最后在 CORE 中搜索。一个给定的应用程序会调用许多程序，这些程序都是按此顺序查找的（想想 Windows 下的 exe 文件和 PATH）。
我们也有 Java 程序与这些遗留代码进行交互，并且由于核心-组-客户查找机制不能轻易地借给 Java，它倾向于在每个客户的 CVS 分支中增长，需要太多的维护。Java 部分和后端部分倾向于并行开发。
我被指派想办法让两个世界相遇。
本质上，我们想要一个 Java 环境，它允许我们拥有一个包含每个版本的源代码的单一代码库，在这里我们可以轻松地选择一个组和一个客户，并为该客户使用应用程序，然后轻松切换到另一个代码集和那个客户。
我正在考虑一个场景，其中每个核心、客户和组都有一个 Eclipse 项目，然后使用项目集来选择给定场景所需的那些。我无法理解的问题是，我们将如何在 CORE 项目中创建健壮的代码，无论选择哪个组和客户，这些代码都将起作用。一个工厂类，它知道调用传递的 Class 对象的哪个子类而不是每个新的？
其他人一定有类似的代码库管理问题。有没有人有经验分享一下？
编辑：上述问题的结论是，CVS 需要替换为更适合同时处理许多分支的源代码管理系统，以及在保留历史记录的同时将源代码从一个组件迁移到另一个组件。受最近 slf4j 和 logback 迁移的启发，我们目前正在研究 git，因为它可以很好地处理分支。我们也考虑过颠覆和善变，但 git 似乎更适合单一位置、多分支的项目。我在另一个问题中询问过 Perforce，但我个人倾向于开源解决方案来解决与此一样重要的问题。
编辑：经过深思熟虑，我们发现我们真正的痛点是我们在 CVS 中使用分支，如果您对所有文件进行分支，CVS 中的分支是最容易使用的！修改后的结论是，我们可以单独使用 CVS 来做到这一点，通过切换到 Java 项目林，每个项目对应于上述一个级别，并使用 Eclipse 构建路径将它们联系在一起，以便每个客户版本都拉入适当的 GROUP和核心项目。我们仍然希望切换到更好的版本控制系统，但这是一个非常重要的决定，所以我们希望尽可能地推迟它。
编辑：我现在使用 Google Guice 2.0 对 CORE-GROUP-CUSTOMER 概念进行了概念验证——@ImplementedBy 标签正是我们所需要的。我想知道其他人是做什么的？到处都在使用 if 吗？
编辑：现在我也需要这个功能用于 Web 应用程序。Guice 在 JSR-330 到位之前一直存在。任何有版本控制经验的人？
编辑：JSR-330/299 现在与基于 JBoss Seam 的 JEE6 参考实现 Weld 一起使用，我已经用 Weld 重新实现了概念验证，并且可以看到如果我们在 bean 中使用 @Alternative 和 ...。 xml 我们可以得到我们想要的行为。即为 CORE 中的给定功能提供新的实现，而无需在 CORE jar 中进行任何更改。对 Servlet 3.0 规范的初步阅读表明它可能支持 Web 应用程序资源（而不是代码）的相同功能。我们现在将对实际应用程序进行初步测试。