Version control 从一个代码库开发多个产品的策略

我正在从事一个项目，该项目将（很快）分为多个不同的版本（试用版、专业版、企业版等）

自从Subversion第一次发布（以及之前的CVS）以来，我就一直在使用它，所以我对分支和标记的抽象概念很熟悉。但在我所有的开发经验中，我只真正研究过主干代码。在少数情况下，其他一些开发人员（拥有存储库）要求我将更改提交到某个分支，而我只做他要求我做的任何事情。我认为“合并”是一种离奇的黑色艺术，我只是在仔细的监督下才尝试过的。 但在这种情况下，我负责存储库，这种事情对我来说是全新的

绝大多数代码将在所有产品之间共享，因此我假设代码将始终驻留在主干中。我还假设每个版本都有一个分支，每个产品的发布版本都有标签

但除此之外，我知道的不多，我相信有一千零一种不同的方式可以把事情搞砸。如果可能的话，我想避免把事情搞砸

例如，假设我想为pro和enterprise版本开发一个新功能，但我想从演示版本中排除该功能。我将如何做到这一点

在我的日常开发中，我还假设我需要在工作时将开发快照从一个分支切换到另一个分支（或切换回主干）。以尽量减少混乱的方式，最好的方法是什么

你们还有什么其他的策略、指导方针和建议

---

更新：

那好吧

看来分支根本不是正确的策略。所以我改变了问题的标题，去掉了“分支”的焦点，并且我扩大了问题的范围

我想我的其他一些选择是：

1） 我可以始终分发软件的完整版本，包括所有功能，并使用许可证根据许可证中的授权有选择地启用和禁用功能。如果我走这条路，我可以想象一个由If/else块组成的老鼠窝会调用某种类型的单例“license manager”对象。在这种情况下，避免代码滥用职权的最佳方法是什么

2） 我可以使用依赖注入。但一般来说，我讨厌它（因为它将逻辑从源代码移动到配置文件中，这使得项目更难进行摸索）。即便如此，我仍在分发完整的应用程序，并在运行时选择功能。如果可能，我不希望将企业版二进制文件分发给演示用户

3） 如果我的平台支持条件编译，我可以使用#IFDEF块和构建标志来选择性地包含功能。这对于大型、笨重的功能（如整个GUI面板）来说效果很好。但是，对于小型的、跨领域的音乐会，比如日志记录或统计跟踪，又如何呢

---

4） 我正在使用ANT来构建。是否有类似于ANT的构建时依赖项注入的功能？

是否希望通过Subversion实现这一功能？我会使用Subversion来维护不同的版本（每个版本有一个分支，例如v1.0、v2.0等），但我会考虑从同一代码库构建不同的版本（试用版/专业版等）

这样，您只需通过构建启用或禁用各种功能，而不必担心同步不同的分支。如果您使用Subversion来管理不同的发行版和不同的版本，我可以看到在不久的将来分支/标记的爆炸式增长

---

对于切换，您可以简单地维护签出的代码库，并使用签出不同的版本。这比为每个交换机执行新的签出要省时得多。

您没有那么快地跳转到分支和合并购物车上是正确的。这是一个皮塔

我想要分支subversion存储库的唯一原因是我想与其他开发人员共享我的代码。例如，如果您一起处理某个功能，但尚未完成，则应使用分支进行通信。否则，我会尽可能多地待在后备箱上

---

我支持Brian的建议，即区分基于构建的版本，而不是基于代码库的版本。

这是一个非常有趣的问题。我喜欢分发所有内容，然后使用许可证密钥启用和禁用某些功能。您有一个合理的顾虑，那就是检查代码并继续检查用户是否获得特定功能的许可需要做大量工作。听起来很像是在java中工作，所以我建议您考虑使用aspect weaver在构建时插入代码进行许可证检查。仍然会有一个对象，所有对许可证检查的调用都会进入该对象，但是如果您使用的是方面，那么这并不是一个坏的做法，我认为这是一个好的做法

在大多数情况下，您只需要在获得许可的情况下进行读取，并且您将拥有少量的组件，因此表可以一直保存在内存中，并且因为它只是读取，所以在线程方面不应该有太多问题

---

作为替代方案，您可以分发许多JAR，每个组件一个JAR，并且只允许加载许可的类。要实现这一点，您必须绑定到类加载器中

我不建议使用“switch”，因为它可能会中途失败（例如，当未版本化的文件妨碍已版本化的文件时），从而使您只能使用部分已切换的工作副本。每个分支有一个签出将减少混乱。