在 SVN 中存储二进制文件有不同的方法吗？如果是这样，它们是什么，以及我如何修改存储选项？
我读到有 4 种方法可以在 SVN 中存储二进制文件：
哪些对时间效率最有用？以及如何设置 SVN 以使用这些方法中的任何一种？
谢谢，奥德。
我有许多小型二进制文件和一些大型二进制文件。都经常更换。我目前正在研究 CVS 并很快切换到 SVN，我想知道存储二进制文件的方法。
我阅读了Performance tune Subversion（上面提到过），发现它很有用，但没有给出示例，所以我并不完全理解如何执行他建议的4种方法中的每一种。
我的基本问题是天气或默认设置是否良好（它们是什么？）我首先考虑的是时间效率，然后是空间。谢谢 ：）
您没有将 Subversion 设置为使用任何这些方法，而是指定将文件放入存储库时使用的方法。“方法”，我不是指你提到的 4 个中的任何一个，而只是“导入”或“提交”，每次你想存储一个新文件时，你必须不断告诉 Subversion 选择的方法将该文件修订到存储库中。
请参阅性能调优 Subversion。
从那里的描述中可以看出，为了使用“方法1”，压缩成tar然后使用import，他们必须自己将所有二进制文件压缩成一个.tar文件，然后使用Subversion的import命令来将文件添加到存储库中。
另请注意，导入命令将文件存储为新文件，而不是先前版本的增量，因此如果对大文件的更改很少，它可能会节省时间，但不节省空间。
Subversion 本身只做提交和导入。提交是对现有文件的新修订，存储为一系列增量（或新文件的第一个修订，不是），导入只是一个新文件。其他任何事情你都必须自己做。
如果二进制文件只是不时更改，这可能值得进一步研究，但如果它们定期更改，我建议像平常一样使用 Subversion，使用 commit 命令。
另请注意，关于二进制文件的典型建议是，如果可能，您应该将源代码存储到生成这些二进制文件的任何位置，而不是二进制文件，然后重新运行工具以重现实际的二进制文件. 如果二进制文件的复制需要时间或空间，那么您也只能存储有问题的二进制文件。
二进制文件存在不好比较的问题，因此如果开发人员 a 和 b 都检索到最新版本，然后开发人员 a 在开发人员 b 尝试执行相同操作之前提交新版本，则会发生某种类型的冲突。开发人员 B 可能别无选择，只能自己尝试找出更改。
编辑：让我强调我所说的 COMMIT 和 IMPORT 的意思。
主要区别在于，假设您已经在存储库中拥有该文件，COMMIT 将尝试将您的工作副本中的文件与以前的存储库版本进行比较，并仅存储更改。这需要时间和内存来解决这些差异，但通常会导致您的存储库中出现一个小的修订变更集。换句话说，您的 Subversion 服务器上的磁盘空间将比使用 IMPORT 命令受到的影响要小。
另一方面，IMPORT 将导入新文件，就好像你刚刚给它一个新文件并说“忘记前一个，只存储这个文件”，因此不会花费时间或内存来计算差异，但存储库中生成的变更集会更大。换句话说，Subversion 服务器上的磁盘空间会比 COMMIT 命令受到更大的影响，但 IMPORT 通常会运行得更快。
您想要强加的任何其他工作流程都必须在 Subversion 之外完成。这包括您的操作系统中可用的 TAR 命令和压缩选项。如果您想使用“方法 1”，您自己必须手动将要导入的文件压缩到单个 .tar 文件中，然后再将其提供给 Subversion。你不能要求 Subversion 为你做任何事情。您当然可以制作脚本文件，使该过程在某种程度上自动化，但这仍然不是 Subversion 问题。
我会对此进行一些认真的测试，以确定这些收益是否真的值得您在 Subversion 工作流程中进行的额外工作。
你能更详细地描述一下你的情况吗？
您是否有几个一起更改的小型二进制文件？几个独立更改的大型二进制文件？您的文件是否经常更改？
Have you actually found that the defaults aren't good enough? I've always just added binary files in the same way as normal and found it to just work. Like any performance problem, I wouldn't try to make things complicated unless you've got a good reason to - in which case, please share that reason with us.