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

修订号.每个项目存储库都有单独的修订序列.

Revision numbers. Each project repository will have separate revisions sequence.

粒度.对于每个项目的存储库，您无法提交到具有相同修订号的不同项目.我更多地认为这是优势，而有人会说这是一个缺陷.

Granularity. With repository per project you just can't make a commit into different projects having the same revision number. I assume this more as advantage, while someone would say that it is a flaw.

存储库大小.你的项目有多大?它有源代码控制下的二进制文件吗?我敢打赌它有.因此，大小很重要 - 二进制文件的每次修订都会增加存储库的大小.最终它变得笨拙并且难以支持.应支持二进制文件存储的细粒度策略，并提供额外的管理.至于我，我仍然找不到如何从存储库中完全删除二进制文件(由一些愚蠢的用户提交)及其内容历史记录.使用每个项目的存储库会更容易.

Repository size. How large is your project? Does it have binaries under source control? I bet it has. Therefore, size is important - each revision of binary file increases size of the repository. Eventually it becomes clumsy and it's hard to support. Fine-grained policy of binary files storage should be supported, and additional administration provided. As for me, I still can't find how could I completely delete binary file (committed by some stupid user) and its contents history from repository. With repository per project it would be easier.

内部存储库组织.我更喜欢细粒度、非常有组织、自包含、结构化的存储库.有一个图表说明了存储库维护过程的一般(理想)方法.我想您会同意，不可能在一个仓库中使用所有项目"的方法.例如，我的仓库初始结构(每个项目仓库都应该有)是:

Inner repository organization. I prefer fine-grained, very organized, self contained, structured repositories. There is a diagram illustrating general (ideal) approach of repository maintenance process. I think you would agree that it is just NOT POSSIBLE to use 'all projects in one repo' approach. For example, my initial structure of repository (every project repository should have) is:

回购管理.每个项目的存储库"在用户访问配置中有更多的可能性.虽然它更复杂.但也有一个有用的功能:您可以配置存储库以使用相同的配置文件

Repo administration. 'Repository per project' has more possibilities in users access configuration. It is more complex though. But there is also helpful feature: you can configure repositories to use the same config file

回购支持.我更喜欢单独备份存储库.有人说，在这种情况下，不可能将一个 repo 中的信息合并到另一个 repo 中.你到底为什么需要那个?需要这种合并的情况表明源代码控制的初始方法是错误的.项目的演变假设后续项目分离为子模块，而不是相反.我知道有办法做到这一点.

Repo Support. I prefer backing up repositories separately. Somebody says that in this case it is not possible to merge info from one repo into the other. Why on earth you would need that? The case when such merge is required shows that initial approach to source control is wrong. Evolution of the project assumes subsequent project separation into submodules, not the other way. And I know that there is approach to do that.

svn:externals.每个项目的存储库"方法鼓励使用 svn:externals.当项目和子模块之间的依赖关系通过软链接建立时，这是一种健康的情况，即 svn:externals.

svn:externals. 'Repository per project' approach encourages svn:externals usage. That is a healthy situation when dependencies between project and submodules is established via soft links, which svn:externals is.

结论.如果您想保持源代码控制简单，请使用 one 存储库.如果你想使软件配置管理正确:

Conclusion. If you want to keep source control simple, use one repository. If you want to make software configuration management RIGHT: