SVN项目结构和有时重叠的多个项目的分支策略

Question

我正在尝试为一个四人小组提出一个可靠的SVN存储库结构和分支策略。我们在任何时候都有四个主要和几个小项目在开发中，项目之间经常有一些重叠。我们当前的策略是完全低效的，包括在单个版本化的“trunk”文件夹下拥有每个文件夹（大约15个左右）。这意味着无论何时我们进行分支，我们都会分支所有15个项目（更新工作副本大约需要20分钟，然后下拉分支，以便将其放入透视图中）。

主要关注的是一些项目重叠，并且一个特性或任务要求在项目A和项目B中更改某些内容并不罕见（所有这些项目都与同一个数据库通信并使用相同的数据库表;此外，他们共享一个业务层，以便更改一个项目中的类将影响另一个项目，因为项目都是一个“伞形”应用程序的基本相关部分。例如，对于主要项目基本上有：

• 项目A：前端电子商务网站
• 项目B：后端履行/管理系统
• 项目C：前端站点的无品牌副本（同样的东西减去CSS样式，功能更少）
• 项目D：Web服务API

A和B交织在一起，但B是一个软件即服务应用程序（我们充当我们自己的客户），C是客户的前端（A作为我们公司的前端，因为C本质上是A，功能较少，没有公司特定的细节）。 D只能由客户访问，但我的最终目标是让A，B和C都通过网络服务使用D的功能（基本上吃我们自己的狗食）。

我们刚刚决定采用为期三周的部署策略（意味着我们每三周进行一次生产部署），而且我们当前的SVN策略非常繁琐，使得分支非常痛苦。

有几个项目有重叠，将它们全部放在一个带有分支/标签/中继格式的项目文件夹下是否有意义，还是应该将它们视为单独的项目？也许结合一些，例如将SaaS前端/后端与我们自己的站点和Web服务分开？

参与类似项目的人的任何建议或意见都会很棒。

Answer 1

这听起来和我公司的项目完全一样。我们遇到了同样的问题，我们默默地放弃了对所有内容使用相同的代码库，并将所有内容拆分为单独的项目，因为这样更容易管理。如果可能的话，您可以为您拥有的公共代码创建单独的项目，然后在所有其他项目中引用这些项目中的dll。我在上一家公司做过后一件事并且有效。这只是意味着如果您更新公共代码，则必须记住将最新的dll复制到当前项目中。

Answer 2

我会尝试这样的事情：

D - 将此作为单独的回购。使用svn：externals包含在需要的其他repos中 B - 将此作为单独的回购。使用svn：externals包含在需要的其他repos中 A - 将其设为单独的仓库，它可以是后备箱 C - 使用与A相同的repo，但将其设为自己的分支。您希望向客户端公开的主干的任何功能，您从主干合并到此分支。