我们是否应该为所有公司提供一个单独的存储库，其中包含许多开发项目或每个项目的存储库？关于经验/最佳实践的任何想法？
答案 0 :(得分：39)
我发现只有一个Subversion存储库可以帮助：
修改 其他原因：
答案 1 :(得分：37)
就个人而言，我肯定更喜欢每个项目的单独存储库。有几个原因：
修订号。每个项目存储库都有单独的修订顺序。
<强>粒度即可。对于每个项目的存储库，您无法提交具有相同版本号的不同项目。我认为这更有利，而有人会说这是一个缺陷。
存储库大小。你的项目有多大？它是否在源代码管理下有二进制文件？我打赌它有。因此，大小很重要 - 二进制文件的每个版本都会增加存储库的大小。最终它变得笨拙而且很难支持。应支持细粒度的二进制文件存储策略，并提供其他管理。至于我，我仍然无法找到如何从存储库中完全删除二进制文件（由一些愚蠢的用户提交）及其内容历史记录。使用每个项目的存储库会更容易。
内部存储库组织。我更喜欢细粒度，非常有组织，自包含，结构化的存储库。有一个diagram说明了存储库维护过程的一般（理想）方法。我想你会同意使用'一个回购'方法中的所有项目是不可能的。例如，我的初始存储库结构（每个项目存储库应该具有）是：
/project
/trunk
/tags
/builds
/PA
/A
/B
/releases
/AR
/BR
/RC
/ST
/branches
/experimental
/maintenance
/versions
/platforms
/releases
回购管理。 “每个项目的存储库”在用户访问配置方面具有更多可能性。但它更复杂。但也有一个有用的功能：you can configure repositories to use the same config file
回购支持。我更喜欢单独备份存储库。有人说，在这种情况下，不可能将信息从一个仓库合并到另一个仓库。为什么你需要那个呢？需要这种合并的情况表明，源控制的初始方法是错误的。项目的演变假设后续项目分离为子模块，而不是其他方式。我知道有办法做到这一点。
<强>的svn：外部对象即可。 “每个项目的存储库”方法鼓励使用svn：externals。当通过软链接建立项目和子模块之间的依赖关系时，这是一个健康的情况，svn：externals是。
<强>结论即可。 如果要保持源代码控制简单，请使用一个存储库。 如果您想进行软件配置管理：
PS。顺便说一句，尽管我一直在使用SVN而且我喜欢它，“每个项目的存储库”方法是我从存储库组织的角度看DCVS系统更具吸引力的原因。在DCVS中，repo是默认的项目。甚至没有“单一与多重”可能的问题，这只是胡说八道。
答案 2 :(得分：16)
我强烈建议不要在每个项目中使用存储库。在单个subversion存储库中，您可以移动和复制数据，它将保留其历史记录。如果您认为作为后端工具启动的某些代码正在合并到前端，并且这些代码位于不同的存储库中，那么这不是颠覆会知道任何操作的操作。就好像你从前端添加了一些东西。这也意味着如果您需要临时维护两个版本的相关代码，则无法进行合并。
您将注意到svn book中的所有示例都假设所有内容都在一个存储库中。
还有一个单独的问题：是使用/ trunk / project1，/ trunk / project2，/ branches / project1-r1还是使用/ project1 / trunk，/ project1 / branches / r1，/ project2 / trunk。一般来说，第二种更容易跟踪。
不将所有内容放在一个存储库中的最佳理由是访问控制很难比存储库级别更精细。可能，是的，但不是那么容易。我们目前有两个主要的存储库：
答案 3 :(得分：8)
这取决于您的应用程序/项目在组织中的相互依赖程度，以及代码库的大小。因此，它归结为如何定义组织中的“项目”。共享代码库，共享组件，共享团队，共享发布周期，都可能影响您的存储库的构建方式。
为简单起见，我将项目定义为具有独立的代码库，发布时间表和/或属于一个工具/应用程序。如果是这种情况，我更喜欢每个项目都有一个存储库。通过这种方式，可以更自由地为每个项目定义和实施策略/访问限制。
如果我的单个存储库随着时间的推移膨胀。我可能还需要担心工作区检出时间等，特别是如果项目的代码都是混合的。如果应用程序/工具/项目已完成/搁置/废弃/迁移，如果在项目级别存在分离，则可以对管理方面进行更多控制。
如果每个项目有一个存储库，那么根据其独特需求构建项目存储库也会更容易。每个项目可能都有特定需求，这可能会影响每个项目遵循的配置管理策略（分支，标记，命名约定，CI等）。这并不是说你不能在单个存储库中完成所有这些文件夹。您可以。它只是让事情更简单，以便更清晰地分离 - 就是这样。
您可能需要考虑所有这些因素，以便根据您的具体设置评估最终可能产生的管理费用。
这就是说，如果项目规模都很小，并且相互依赖，需要交叉引用，交叉跟踪，相互移动等等，那么每个存储库只需一个repo和一个文件夹就可以了。
答案 4 :(得分：3)
我会有一个项目存储库，只是为了每个项目的修订号。您可以设置要服务的SVN，以便可以使用Apache和DAV SVN（使用SVNParentPath指令）从单个访问点访问所有项目。
答案 5 :(得分：3)
到目前为止非常好，有见地的答案，但我只想加上我的两分钱：
我认为这取决于项目的大小。我们已经尝试了这两种方法，但最终确定了一个大型存储库。
<强>缺点：
<强>赞成：
恕我直言（关于我们的特定项目）专业人士超重的缺点。
答案 6 :(得分：1)
如果您使用的是Subversion，则可以在同一个域下拥有多个存储库，每个存储库都有多个项目。
所以它看起来像这样
Project1: svn://svn.company.com/project1
Project2: svn://svn.company.com/project2
Project1可能会解决前端代码并包含子项目，例如admin /和web / Project2将是后端，包含各种工具和监视应用程序
如果您使用类似Git的东西，每个存储库应该是一个项目。
答案 7 :(得分：1)
决定也可能基于项目的复杂性。如果你正在开始一项巨大的努力，将从你将要工作的大多数其他事情中解决，并且它将有一个大的开发团队正在研究它，可能有意义的是给它一个单独的回购。
对于同时处理多个小型项目的团队，单个存储库提供了一种简单的机制来管理一个地方的所有内容（备份，搜索等）。中央仓库也使存储库本身看起来更“具体”，因为一旦项目完成或放弃，它就不会被丢弃。
答案 8 :(得分：1)
这完全取决于您拥有的项目数量，组织规模，项目相关程度等等。如果你是一个拥有几十个项目的大型团队的一员，那么每个项目的存储库将非常难以管理。
根据您的组织的工作类型，另一个选择是每个客户端拥有一个存储库。在我工作的地方，我们目前有四个存储库 - 一个用于完全在我们内部的项目，一个用于我们销售的软件，两个完全特定于特定客户，我们为其生产仅适用于他们的定制软件。这是一个“两全其美”解决方案的尝试 - 我们没有一个包含所有东西的大型存储库，并且有数十亿的修订号（我显然夸大了！），但我们也没有几十个小的存储库每个人都有一个项目。
答案 9 :(得分：0)
对于我的组织，我去了中途，为不同的编码“区域”创建了几个存储库。我事先知道每个存储库都包含彼此相当分离的项目。
答案 10 :(得分：0)
我已经完成了两种情况，在这两种情况下，我有时希望我选择了另一种方法......
我已经确定了一个存储库是一个很好的解决方案。请注意，如果我在一家大公司，我会重新考虑。
答案 11 :(得分：0)
我在一家为很多客户提供严格规定的公司工作。目前我们有大约130名开发人员。我们有一个核心项目，可根据每个客户的需求进行定制。我们有一个庞大的svn存储库。如果我们必须检查整个分支，那将是痛苦的屁股，但我们的策略是将项目移出公共分支并仅将工作留给切换命令。 :)这样一切都可以保存在一个存储库中。
我唯一关心的是如果需要将部分工作分配给多个存储库，或者在我找到这个之前销售整个项目： http://www.mugo.ca/Blog/Splitting-a-Subversion-repository-into-multiple-repositories
所以我认为svn switch减轻了长时间结账的痛苦（一个只切换出所需的项目），但我们可以拥有一个存储库。但是，如果仍然需要，可以提取一组组件来分隔存储库。