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

【问题标题】：SVN project structure and branching strategy for multiple projects that sometimes overlap多个有时重叠的项目的SVN项目结构和分支策略
【发布时间】：2012-05-11 14:15:44
【问题描述】：

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

主要问题是某些项目重叠，并且在项目 A 和项目 B 中需要更改某项功能或任务的情况并不少见（所有这些项目都与同一个数据库通信并使用相同的数据库表; 此外，它们共享一个业务层，因此在一个项目中更改一个类会影响另一个），因为这些项目本质上都是一个“伞形”应用程序的相关部分。例如，对于主要项目，基本上有：

项目A：前端电商网站
项目 B：后端执行/管理系统
项目 C：前端网站的无品牌副本（相同的东西，但 CSS 样式和功能较少）
项目 D：Web 服务 API

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

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

由于多个项目有重叠，将它们全部放在一个具有分支/标签/主干格式的项目文件夹下是否有意义，或者我们应该将它们视为单独的项目？也许结合一些，例如将 SaaS 前端/后端结合在一起，我们自己的网站和 Web 服务是分开的？

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

【问题讨论】：

你有没有考虑过使用 Git(git-scm.com) 代替 svn？ GIT 的主要宣传功能之一是能够以比 svn 更简单的方式进行分支。希望这会有所帮助。
是的；我们之前也在评估 Mercurial，但是学习曲线被证明是一个问题，所以为了不要太快引入太多变化，我们被 SVN 困住了。尝试学习 Mercurial/Git 是“太难了”并导致了问题......

标签： .net svn project-structure branching-strategy

【解决方案1】：

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

【讨论】：

【解决方案2】：

我会尝试这样的事情：

D - 将此作为单独的存储库。使用 svn:externals 将其包含在其他需要的存储库中。
B - 将此作为单独的存储库。在需要的地方使用 svn:externals 包含在其他存储库中。
A - 将此作为单独的存储库，它可以作为主干。
C - 使用与 A 相同的存储库，但将其设为自己的分支。您想要向客户端公开的任何来自主干的功能，您都可以从主干合并到这个分支。

【讨论】：

那么你真的会推荐使用完全不同的repository吗？我的初衷是拥有一个包含单个项目文件夹（带有分支/标签/主干）的单一存储库，以便更轻松地合并文件。
是的，这些是单独的存储库。除非我弄错了，否则我认为除了 A 和 C 之间不需要任何合并，所以它们在同一个仓库中。
嗯，没错。我正在考虑 C 是 B 的一部分（作为前端）而不是 A，尽管您是正确的，A 和 C 共享很多逻辑，因此如果 C 和 B 在一起但 A 是在自己的存储库中；然而，由于 SEO 原因（不能失去 7 年以上的 SEO），除了错误修复和一些小的增强功能之外，A 在开发中有点“冻结”，而 C 和 B 计划进行重大重构（不是完全重写，但接近) 以使它们更密切相关。