我正在开发一个将(很快)会分支到多个不同版本(试用版,专业版,企业版等)的项目。从一个代码库开发多个产品的策略
自从它首次发布(以及之前的CVS)以来,我一直在使用Subversion,所以我很喜欢分支和标签的抽象概念。但是在我所有的开发经验中,我只有真正的中继代码。在少数情况下,其他一些开发人员(拥有存储库)要求我对某个分支提交更改,而我只是做了他要求我做的任何事情。我认为“合并”了一件奇异的黑色艺术,而我只有在仔细的监督下才尝试过。
但在这种情况下,我负责存储库,这种事情对我来说是全新的。
绝大多数代码将在所有产品之间共享,所以我假设代码将始终驻留在主干中。我还假设每个版本都有一个分支,每个产品的发布版本都有标签。
但是除此之外,我不太了解,而且我确信有一千种和一种不同的方法可以解决这个问题。如果可能的话,我想避免把它搞砸。
例如,假设我想为专业版和企业版开发一项新功能,但我想从演示版本中排除该功能。我将如何实现这一目标?
在我的日常开发中,我还假设我需要在工作时将我的开发快照从分支切换到分支(或回到主干)。最大限度地减少混淆的方法是什么?
你们有什么其他的策略,指导方针和技巧建议?
UPDATE:
好了,没事呢。
看起来分支并不是正确的策略。所以我改变了问题的标题以消除“分支”焦点,并且我正在拓宽这个问题。
我想我的一些其他的选项有:
1)我总是可以分发完整版的软件,具有所有功能,并使用许可基于许可授权,以选择性地启用和禁用功能。如果我采用这条路线,我可以想象一个鼠标嵌套的if/else块调用某种单身“许可证管理器”对象。在这种情况下避免代码面条的最好方法是什么?
2)我可以使用依赖注入。但一般来说,我讨厌它(因为它将逻辑从源代码移到配置文件中,这使得项目变得更加困难)。即使如此,我仍然在分发完整的应用程序并在运行时选择功能。如果可能,我宁愿不将企业版本二进制文件分发给演示用户。 3)如果我的平台支持条件编译,我可以使用#IFDEF块并构建标志来选择性地包含特征。这对于像整个GUI面板这样大而笨重的功能很适用。但是对于较小的交叉音乐会,例如记录或统计跟踪呢?
4)我正在使用ANT构建。是否有类似ANT的构建时间依赖注入?
我不会推荐使用'switch',因为它可能会中途失败(例如,当未版本控制的文件阻塞了版本控制的文件时)给您部分切换的工作副本。为每个分支结账将减少混淆。 – 2009-06-02 12:13:01