2009-05-31 97 views
6

我正在开发一个将(很快)会分支到多个不同版本(试用版,专业版,企业版等)的项目。从一个代码库开发多个产品的策略

自从它首次发布(以及之前的CVS)以来,我一直在使用Subversion,所以我很喜欢分支和标签的抽象概念。但是在我所有的开发经验中,我只有真正的中继代码。在少数情况下,其他一些开发人员(拥有存储库)要求我对某个分支提交更改,而我只是做了他要求我做的任何事情。我认为“合并”了一件奇异的黑色艺术,而我只有在仔细的监督下才尝试过。

但在这种情况下,我负责存储库,这种事情对我来说是全新的。

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

但是除此之外,我不太了解,而且我确信有一千种和一种不同的方法可以解决这个问题。如果可能的话,我想避免把它搞砸。

例如,假设我想为专业版和企业版开发一项新功能,但我想从演示版本中排除该功能。我将如何实现这一目标?

在我的日常开发中,我还假设我需要在工作时将我的开发快照从分支切换到分支(或回到主干)。最大限度地减少混淆的方法是什么?

你们有什么其他的策略,指导方针和技巧建议?


UPDATE:

好了,没事呢。

看起来分支并不是正确的策略。所以我改变了问题的标题以消除“分支”焦点,并且我正在拓宽这个问题。

我想我的一些其他的选项有:

1)我总是可以分发完整版的软件,具有所有功能,并使用许可基于许可授权,以选择性地启用和禁用功能。如果我采用这条路线,我可以想象一个鼠标嵌套的if/else块调用某种单身“许可证管理器”对象。在这种情况下避免代码面条的最好方法是什么?

2)我可以使用依赖注入。但一般来说,我讨厌它(因为它将逻辑从源代码移到配置文件中,这使得项目变得更加困难)。即使如此,我仍然在分发完整的应用程序并在运行时选择功能。如果可能,我宁愿不将企业版本二进制文件分发给演示用户。 3)如果我的平台支持条件编译,我可以使用#IFDEF块并构建标志来选择性地包含特征。这对于像整个GUI面板这样大而笨重的功能很适用。但是对于较小的交叉音乐会,例如记录或统计跟踪呢?

4)我正在使用ANT构建。是否有类似ANT的构建时间依赖注入?

回答

2

一个最有趣的问题。我喜欢分发所有内容然后使用许可证密钥来启用和禁用某些功能的想法。您有一个有效的担忧,即需要通过代码进行大量工作,并继续检查用户是否获得某项功能的许可。这听起来很像你在用java工作,所以我建议你看看使用方面编织器在构建时插入用于许可证检查的代码。所有的许可证检查请求仍然会有一个对象,但如果您使用某个方面,它不会像实践那样糟糕,我会说这是一个很好的做法。

对于大多数情况,只需要阅读是否获得许可,并且只需要少量的组件,以便表格可以随时保存在内存中,因为它只是读取您不应该拥有的内容线程有很多麻烦。

作为一种替代方案,您可以分发许多罐,每个组件都有许可证,并且只允许加载许可的类。你将不得不绑定到类加载器来实现这一点。

2

你想通过Subversion来做到这一点吗?我会使用Subversion来维护不同的版本(每个版本的分支,例如v1.0,v2.0等),但是我会考虑从相同的代码库构建不同版本(试用版/专业版等)。

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

对于切换,您可以简单地维护检出的代码库,并使用svn switch来检出不同的版本。这比每个交换机执行新的签出要花费的时间少得多。

+0

我不会推荐使用'switch',因为它可能会中途失败(例如,当未版本控制的文件阻塞了版本控制的文件时)给您部分切换的工作副本。为每个分支结账将减少混淆。 – 2009-06-02 12:13:01

1

你是对的,不要在如此快的分支和合并车上跳。这是一个PITA。

我想要分支Subversion版本库的唯一原因是如果我想与另一个开发人员共享我的代码。例如,如果您一起工作并且尚未完成,则应使用分支进行通信。否则,我会尽可能留在主干上。

我第二次推荐Brian来区分版本上的版本而不是代码库上的版本。