多个SVN存储库或单个公司存储库

我们是否应该为所有公司（包含许多开发项目）或每个项目的存储库拥有一个单一的存储库？ 任何经验/最佳实践的想法？

Answer 1

就个人而言，我肯定会喜欢每个项目单独的存储库 有几个原因：

1. 版本号 每个项目存储库将有单独的修订顺序。

2. 粒度 。 使用每个项目的存储库，您不能对具有相同版本号的不同项目进行提交。 我认为这更有利，而有人会说这是一个缺陷。

3. 存储库大小 。 你的项目有多大？ 它有源代码控制下的二进制文件吗？ 我敢打赌，它已经。 因此，大小很重要 – 二进制文件的每个修订都会增加存储库的大小。 最后它变得笨拙，很难支持。 应该支持二进制文件存储的细粒度策略，并提供额外的pipe理。 至于我，我仍然无法find如何从存储库中彻底删除二进制文件（由一些愚蠢的用户提交）及其内容的历史。 每个项目的存储库会更容易。

4. 内部存储库组织 。 我更喜欢细粒度的，非常有组织的，自包含的结构化存储库。 有一个图表说明了库维护过程的一般（理想）方法。 我认为你会同意在一个回购中使用“所有项目”是不可能的。 例如，我的初始仓库结构（每个项目仓库都应该有）是：

   /project /trunk /tags /builds /PA /A /B /releases /AR /BR /RC /ST /branches /experimental /maintenance /versions /platforms /releases 

5. 回购pipe理 。 “每个项目的存储库”在用户访问configuration中有更多的可能性。 虽然这是比较复杂的。 但也有一个有用的function： 您可以configuration存储库使用相同的configuration文件

6. 回购支持 。 我更喜欢单独备份存储库。 有人说，在这种情况下，不可能将信息从一个回购合并到另一个。 你为什么要这样做？ 需要这种合并的情况表明，初始的源控制方法是错误的。 项目的演变假定后续项目分为子模块，而不是其他方式。 而且我知道有办法做到这一点。

7. svn：外部 。 “每个项目的存储库”方法鼓励svn：外部使用。 这是一个健康的情况，当项目和子模块之间的依赖通过软链接build立，其中svn：externals是。

   结论 。 如果你想保持源代码控制简单，使用一个存储库。 如果你想做软件configurationpipe理右：

   1. 使用“每个项目库”方法
   2. 引入软件configurationpipe理员的独立angular色，并指派团队成员
   3. 聘请优秀的pipe理员，谁可以应付所有的颠覆技巧:)

PS。 顺便说一下，尽pipe我一直都在使用SVN，而且我也喜欢它，但是“每个项目的存储库”方法就是为什么我从存储库组织的angular度看到DCVS系统更具吸引力的原因。 在DCVS回购是默认的项目。 甚至毫无疑问，“单一对多重”是可能的，这只是无稽之谈。

Answer 2

我发现拥有一个Subversion版本库有助于：

1. 透明度 ：更容易遵循正在发生的事情，甚至可以在不直接涉及的项目中查找代码。
2. 维护 ：每次创build新项目时都不需要创build存储库，您可以删除整个项目，而不必担心会丢失Subversion的logging。
3. 维护 ：只需要备份一个存储库。

编辑：其他原因：

• 全球修订ID – 通过修订ID为全球是：
  1. 更容易沟通 （例如，在代码审查请求中，只需指定修订标识，而无需指定哪个项目）。
  2. 当项目彼此依赖时，更容易保证primefaces性 。
  3. 更容易看到提交到不同项目的顺序 。

Answer 3

我强烈build议不要使用每个项目的存储库。 在一个Subversion版本库中，您可以移动和复制数据，并保留其历史logging。 如果你决定将一些作为后端工具开始的代码合并到前端，并且这些代码位于不同的存储库中，那么这不是一个颠覆了解的事情。 这就好像你从什么地方添加了一些东西到前端。 这也意味着如果您需要临时维护两个版本的相关代码，则不能进行合并。

你会注意到， svn书中的所有例子都假设一切都在一个仓库中。

还有一个单独的问题：是使用/ trunk / project1，/ trunk / project2，/ branches / project1-r1还是使用/ project1 / trunk，/ project1 / branches / r1，/ project2 / trunk。 一般来说，第二个更容易跟踪。

不把所有东西都放在一个存储库中的最好的理由是，访问控制很难做到比在存储库级别上更细致。 可能的，是的，但并不那么容易。 我们目前有两个主要的仓库：

• 所有软件开发的svn / code，都需要jira ticket来提交
• svn / ops的任何configuration，设置脚本，第三方焦油，不pipe，不需要jira

Answer 4

这取决于你的应用程序/项目在组织中的相互依赖程度，也取决于代码库有多大。因此，这取决于你在组织中如何定义“项目”。 共享的代码库，共享的组件，共享的团队，共享的发布周期，都可能影响你的存储库的结构。

为简单起见，我将项目定义为具有独立的代码库，发布时间表和/或属于一个工具/应用程序。如果是这种情况，我更喜欢每个项目有一个存储库。 这样，每个项目就有更多的自由来定义和实施政策/访问限制。

如果随着时间的推移，我有一个单一的资源库膨胀..我可能还需要担心工作区结帐时间等，特别是如果项目的代码都混合在一起。 如果一个应用程序/工具/项目完成/搁置/废弃/迁移，如果在项目层面存在分离，则可以对pipe理方面进行更多的控制。

如果每个项目有一个存储库，则基于其独特需求构build项目存储库也可能更容易。 每个项目可能都有特定的需求，这可能会影响每个项目所遵循的configurationpipe理策略（分支，标记，命名约定，CI等）。 这并不是说你不能在单个存储库中以文件夹的方式完成所有这些。 您可以。 它只是让事情更简单，有一个更清洁的分离 – 就这些。

您可能需要考虑所有这些因素，以便根据您的具体设置来评估最终可能导致的pipe理费用。

这就是说，如果项目规模都很小，相互依赖，需要交叉引用，交叉跟踪，彼此间的移动等，那么每个存储库最好用一个回购站和一个文件夹。

Answer 5

我将有一个项目的存储库，只是为了每个项目的修订号。 您可以设置SVN以便使用Apache和DAV SVN（使用SVNParentPath指令）从一个访问点访问所有项目。

Answer 6

非常好，有见地的答案，但我只想补充我的两分钱：

我认为这取决于你的项目的规模。 我们已经尝试了两种方法，但是最后还是用一个大型仓库来解决。

缺点 ：

• 分支可能很困难，因为可能涉及许多文件夹和文件
• 存储库可能变得很大
• 你必须检查整个存储库（或至less特定的分支机构）来build立你的解决scheme
• 对项目架构的一点控制（见优点）

优点 ：

• 所有项目共享相同的资料库历史logging
• 分支是为整个存储库
• 更less的pipe理（个人开发人员可以创build新的项目，而不需要系统pipe理员的帮助）
• 资源库提交的更好的概述和监视选项

恕我直言（和我们的特定项目）的利弊超重的缺点。

Answer 7

如果你使用的是Subversion，你可以在同一个域下有多个存储库，每个存储库有多个项目。

所以它看起来像这样

 Project1: svn://svn.company.com/project1 Project2: svn://svn.company.com/project2 

Project1可能涉及前端代码，并包含诸如admin /和web / Project2等子项目将作为后端，并包含各种工具和监视应用程序

如果你使用类似Git的东西，每个仓库应该是一个单一的项目。

Answer 8

这个决定也可能是基于项目的复杂性。 如果你开始了大量的工作，将会从你所要做的大部分工作中分离出来，而且还会有一个大型的开发团队来进行工作，所以给它一个单独的回购可能是有意义的。

对于同时处理多个小型项目的团队，单个存储库提供了一个简单的机制来pipe理一个地方的所有内容（备份，search等）。 中央仓库也使仓库本身看起来更加“具体”，因为一旦项目完成或放弃，仓库不会被丢弃。

Answer 9

这完全取决于你有多less个项目，你的组织的规模，项目的相关程度等等。 如果你是一个拥有几十个项目的大型团队的一部分，那么每个项目的一个仓库pipe理将是相当笨拙的。

根据您的组织的工作types，另一种select是每个客户端都有一个存储库。 在我工作的地方，我们目前有四个仓库 – 一个用于我们完全内部的项目，一个用于我们销售的软件，另外两个完全针对特定客户，我们只为他们生产定制软件。 这是一个“两全其美”解决scheme的尝试 – 我们没有一个庞大的存储库，其中包含了所有内容，并且数十亿的版本号（显然我夸大了！），但是我们也没有几十个小的存储库每个项目都有一个项目。

Answer 10

对于我的组织，我中途去了，为不同的编码“区域”创build了一些存储库。 我事先知道每个存储库都包含相互独立的项目。

Answer 11

我已经完成了这两种情况，有时我希望我select了另一种方法。

我已经解决了一个存储库是一个很好的解决scheme。 请注意，如果我在一家较大的公司，我会重新考虑。

Answer 12

我在一家为严格规定的许多客户工作的公司工作。 目前我们有大约130个开发人员。 我们有一个核心项目是根据每个客户的需求定制的。 我们有一个巨大的svn仓库。 如果我们不得不查看整个分支，那将是一件痛苦的事情，但是我们的策略是将这些项目移出公共分支，并且仅仅为了切换命令而离开工作。 :)这样一切都可以保存在一个单一的存储库。

我唯一担心的是如果需要的话，将库分割成多个库，或者出售整个项目，直到find这个： http : //www.mugo.ca/Blog/Splitting-a-Subversion -repository -进入-多库

所以我认为svn开关可以缓解长时间结账的痛苦（只需要切换所需的项目），但是我们可以有一个仓库。 但是，如果仍然需要，可以提取一组组件来分离存储库。