我将项目定义为包含主干、分支、标签子目录的 SVN 目录。
在确定何时将项目拆分为两个或将多个项目合并为一个时，您使用什么标准？ - 每个“项目”一个应用程序，具有用于公共源和资源的共享项目？- 一个包含应用程序所有源和资源的大“项目”？
单项目或多项目都有其优点和缺点。我们正朝着一个单一的项目迈进，我正试图弄清楚这是否是正确的方法。
拆分项目允许更好地控制套件的不同部分如何合并更改。公共库可以是版本，不同的应用程序可以选择使用特定版本（maven dep 管理方法）。
拆分项目还会创建多个类层次结构，使代码整体更难理解，并可能导致代码重复。我认为适当设计整体结构和组件之间的关系将是管理此成本的关键。
统一的项目方法将使开发人员在设置工作空间方面更容易，并提供单一的类层次结构。这是一把双刃剑，因为它还会向开发人员提供更多信息（太多类无法理解）。
所以，当你试图决定在哪里合并和在哪里拆分时，你使用什么经验法则？
我们将与单个应用程序相关的所有项目都放在一个 SVN Rep 中，只是为了便于维护，将应用程序的代码库仅集中在一个存储库中，并且还能够管理应用程序不同资源之间的相互依赖关系。
我们通常将我们的资源分类到主干内的不同文件夹中。该分类主要基于功能/模块化分组或分层分组[DAL、BLL、GUI等]。这完全取决于您如何构建代码。希望这可以帮助。
SVN Book对这两种方法都有很好的讨论。
最后，我会选择对存储库用户来说更自然的东西。
就个人而言，我更喜欢单一的 SVN 主干/标签/分支方法，我所有的实际代码项目都在它们自己的文件夹中。
但是，对于更大的代码库（我只管理了 3-4 个属于单个解决方案的小项目），我会高度考虑更改为拆分方法。
我根据项目规模使用单独的项目和组合项目。对于我们的大型项目，每个项目都在一个单独的存储库中，并且具有独立的构建和部署过程。对于我们较小的项目，我们有一个“工具”存储库来包含它们，每个子项目都作为根的子目录。
我还维护一个“个人”存储库，人们可以在其中存储他们的测试程序一次性实用程序，或其他可以从源代码控制和集中备份中受益但不属于独立项目的东西。
我使用单独的项目并通过 svn:externals 将它们组合成一个解决方案。
每个项目独立部署的一个应用程序/模块。如果你发现你需要一个依赖于其他模块的稳定实现的模块的 Maven 式依赖管理，那么使用单个项目就很难引入发布周期。它还可能导致人们直接使用来自其他应用程序的随机有用的代码，而不是将其分解以保持依赖关系图健全 (tm)。
您应该使用适当的测试套件和明确定义的 CI 实践进行集成测试，而不是依赖于一半的代码在某个部分中断时突然失败。
拥有单个超级项目的另一个问题是，对于仅在单个模块上工作的 git-svn 用户来说，它相当繁重。
有机地成长。Dijkstra 曾经说过，预优化是万恶之源。还要记住 YANGI（你不需要它）。
每个应用程序都有自己的带有主干/标签/分支的文件夹。如果应用程序中的项目变得非常大，那么它会被推送到它自己的单独文件夹，并且可以在构建时链接到应用程序（甚至是 svn:externals）。
也就是说，如果您的项目要求是开发一个由 10 个开发人员编写的复杂应用程序，并且您是看门人或构建大师，那么您可以考虑更复杂的替代方案。
为单独的项目保留单独的 SVN 存储库。你最不想要的就是有一个合并日
您可能想要跨多个项目检查 Subversion 修订号。
感谢您的输入。我不会“选择”答案，因为我认为所有答案都具有价值。避免过早的优化似乎很关键，就像暂时保持布局尽可能简单一样。我们正在转向包含应用程序的单个项目，因为 90% 的时间我们一起发布所有应用程序。因此，让每个项目一个应用程序使事情复杂化似乎没有意义。即使我们使用 maven，给定版本的所有 maven 工件也可能来自同一个分支。如果需要使用 SVN 历史记录和鱼眼来保持我们的理智，我们可以随时更改它。
我们将重构源代码布局，就像我们重构源代码一样。当一个项目从周长和依赖情况开始“闻起来很糟糕”时，我们将把它分解，但不是在那之前。我可能会及时使用周长而不是空间周长：构建和测试的时间，结帐的时间。如果我有一个 1GB 的树，我可以在 10 分钟内结帐并在 30 分钟内构建/测试，除非我需要经常发布它的一部分，否则我真的不需要分解它。
所以，感谢您的输入。这对我为我的团队制定问题和评估选项非常有帮助。
这里没有“好”的答案，但我认为应该区分包含 1 或 2 个项目的 SVN 存储库和包含 100 个项目的其他存储库。
我维护了一个从 VSS 迁移的 SVN 存储库，其中有数百个“项目”，没有一个是按照主干/分支/标签结构组织的（事实上，我认为这种结构在我之后确实是不必要且无益的） SVN 已经使用了一段时间，当您必须将 2 或 3 个项目标记为单个更改时，它肯定无济于事）。
我们为所有维护的软件维护一个项目目录，在该目录下我们有用于配置的子目录和用于源的另一个目录。在那些我们有产品版本号的情况下——我们实际上抛弃了主干的概念，我们只有标签目录——最大的数字是主干（我们必须这样做，因为我们必须同时支持多个版本的项目）。合并根据需要进行，所以如果我更新项目 A 3.0 版中的错误；我会将这些更改合并到版本 4.0 和 v5.0。
如果我只用 1 或 2 个项目进行回购，我可能会想保留分支/标签结构，但另一方面 - 我可能会在主树中保持目录显式（假设我没有经常发布以定期标记）（我将修订号用作“标记”顺便说一句，并将二进制文件存储在其中。因此，如果我需要获取特定的旧修订版，我可以通过查看日志来获取正确的二进制文件）
考虑到我有一个 10Gb 的存储库，其 revnum 目前已超过 300,000，其中包含许多旧代码以及更新的代码，因此管理起来非常容易。我会向其他人推荐该结构并将再次使用它。
顺便说一句，标签 dir 对我们不起作用的另一个原因是因为每次有错误或更改请求时我们都会发布，无论多么微小。一段时间后，我们的标签目录将无法管理，这就是我们使用 revnum 作为标签的原因 - 我们可以将它与错误跟踪器相关联，以使其更具人类可读性。
所以粗略地总结一下，我们有一个这样的目录结构，其中 v1 和 v2 是产品版本：
maint/source/v1.0/projectA
maint/source/v1.0/projectB
maint/source/v2.0/projectA
maint/source/v2.0/projectB
etc
显然，我们可以在“源”下放置一个分支目录，并在每个子项目下放置一个分支/标签，但是如果我们需要将 2 个子项目作为一个更改请求发布（就像我们经常做的那样），这将变得很棘手。在源目录下放置标签子目录意味着我们标记所有内容，当只有一个子项目被更改时（不符合我们单独跟踪每个子项目的要求）