SVN 优化以保持大型存储库响应 [英] SVN optimizations to keep large repositories responsive

问题描述

我们很高兴在工作中使用 SVN 作为 SCM.目前，我的二进制资产与我们的代码位于同一个 SVN 存储库中.SVN 支持非常大的文件(它流式"传输它们以保持内存使用正常)，但它使一切变得 SLOOWWWWW.我对缓慢的资产版本控制没有意见，但缓慢的文本操作并不是真正可以接受的.

We happily use SVN for SCM at work. Currently I've got our binary assets in the same SVN repository as our code. SVN supports very large files (it transmits them 'streamily' to keep memory usage sane), but it makes everything SLOOWWWWW. I'm ok with slow asset versioning, but slow text operations isn't really acceptable.

现在资产在/trunk/release 下(与十几个/trunk/projects 并排).我们应该将它们保存在单独的存储库中吗?我们还可以做哪些其他优化?我们拥有大约 1 GB 的资产，并且还在不断增长.

Right now assets are under /trunk/release (side by side with a dozen /trunk/projects). Should we keep them in a separate repository? What other optimizations can we do? We have about a GB of assets and growing.

推荐答案

IMNSHO 最好将每个项目保存在自己的存储库中，如果只是为了保持它们之间的修订号分开.如果项目 foo 在六个月内没有更改，但项目 bar 正在积极开发中，为什么 foo 当前的修订号要不断变化.如果两者紧密耦合(就像他们共享一个公共库)，则可能是例外，但即便如此，该库也应该是自己的项目.

IMNSHO its better to keep each project in its own repository, if just for the purpose of keeping the revision numbers separate between them. If project foo hasn't been changed in six months, but project bar is in active development, why should foo's current revision number keep changing. The exception perhaps if the two are tightly couple (like they share a common library), but even then maybe the library should be its own project as well.

二进制资产是一直在变化还是静态的?如果它们是静态的，也许您根本不希望它们在存储库中(只需在其中留一个小占位符即可).

Are the binary assets ever changing at all or are they static? If they are static, maybe you don't want them in the repositories at all (just leave a small place holder in there).

这篇关于SVN 优化以保持大型存储库响应的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！