我们很乐意在工作中将 SVN 用于 SCM。目前,我将二进制资产与我们的代码放在同一个 SVN 存储库中。SVN 支持非常大的文件(它“流式地”传输它们以保持内存使用正常),但它使一切变得缓慢。我可以接受缓慢的资产版本控制,但缓慢的文本操作并不是真正可以接受的。
现在资产在 /trunk/release 下(与十几个 /trunk/projects 并排)。我们应该将它们保存在单独的存储库中吗?我们还能做哪些其他优化?我们拥有大约 1 GB 的资产并且还在不断增长。
我们很乐意在工作中将 SVN 用于 SCM。目前,我将二进制资产与我们的代码放在同一个 SVN 存储库中。SVN 支持非常大的文件(它“流式地”传输它们以保持内存使用正常),但它使一切变得缓慢。我可以接受缓慢的资产版本控制,但缓慢的文本操作并不是真正可以接受的。
现在资产在 /trunk/release 下(与十几个 /trunk/projects 并排)。我们应该将它们保存在单独的存储库中吗?我们还能做哪些其他优化?我们拥有大约 1 GB 的资产并且还在不断增长。
你没有说你已经使用了哪些优化。如果您使用的是 bsdfs,请查看切换到 fsfs 是否会提高性能。如果您有大量修订,请在服务器上切换到更新的版本,并将存储库转换为 1.5 格式。
IMNSHO 最好将每个项目保留在自己的存储库中,如果只是为了保持修订号在它们之间分开。如果项目 foo 在六个月内没有更改,但项目 bar 正在积极开发中,为什么 foo 的当前修订号要不断更改。如果两者紧密耦合(就像他们共享一个公共库),则可能是一个例外,但即便如此,该库也应该是它自己的项目。
二元资产是一直在变化还是静态的?如果它们是静态的,也许您根本不希望它们在存储库中(只需在其中留下一个小占位符)。
您可能会得到的最佳答案是将二进制文件放入单独的目录并使用备用目录功能来管理它们——即在您需要文件之前不要签出文件。然后所有操作都将发生在源文件而不是二进制文件上。
或者,您可以使用相同的机制来提交或更新 - 而不是更新您的工作副本,您可以使用“更新到修订版”,并指定 HEAD 和减少的深度,因此二进制目录不会被更新(直到您需要到)。
您还可以“svnadmin pack”您的存储库,这将提高服务器端的性能。