我搜索了一下，但没有找到满意的答案，所以我想听听你对此的看法。
我有几个工具，我不得不经常更新和部署到几个服务器。源在SVN存储库中管理。
为了省去通过ftp或类似手段将二进制文件复制到生产服务器的麻烦（我无法在服务器上构建项目），我正在考虑在存储库中创建一个区域来将它们提交为好。然后，我可以在需要时从svn服务器中简单地检索最新版本的可执行文件。
由于我不一定要在每次处理源代码时更新/提交二进制文件，因此我不会将二进制文件的文件夹创建为项目的子文件夹。然后（并且应该）承诺二进制文件将是一个单独的，有意识的行为。
--- trunk
--- project1
--- project2
--- built
--- project1
--- project2
据我所知，此设置应该没有问题。我真正喜欢的是将源代码修订版和二进制文件都作为单个标记，以便能够一次性检索所有属于一起的内容。
--- tags/project1/release2/
includes files from
--- trunk/project1/ revision 487 and
--- built/project1/ revision 488
我追求的是什么，我将如何实现它？ 我应该改为寻找解决这个问题的其他方法吗？
答案 0 :(得分：9)
你的设置没什么奇怪的（当我需要保留确切的位时，我正在用构建工具和构建工件做类似的事情。）你想要的布局绝对可能 - “包括”其他分支的特定版本或者你的tags / project1 / release2中的标签，你需要做的只是在tags / project1 / release2上设置svn:externals properties，引用你要引入的源和修订版的URL，然后你就可以了。
答案 1 :(得分：4)
虽然我不能直接回答你的问题，但我会说出另一种方法。
我们有一个单独的文件服务器用于二进制版本，其备份策略类似于SVN服务器的备份策略，并且每个项目都有一个目录，其中包含一个不属于SVN的项目，包括发布目录。二进制版本的整个历史记录存储在此目录中，因此您可以从任何地方（从我们的网络内部）获取二进制文件，而无需SVN，即将其复制到某个生产服务器，将其发送给客户或下载在VM中测试。无需结账或重建。
我发现这个设置比将二进制文件转换为SVN更容易管理。如果您需要具有特定版本的精确二进制文件，它就在那里，前提是该版本已经发布给客户端（但是，为什么您需要一个从未见过太阳光的二进制文件？）。
答案 2 :(得分：2)
我相信这是通过使用“外部”来处理的。但是有一些陷阱，我还没有找到一些我觉得舒服的东西。我使用我的源库做你的建议，但我仍然手动完成。
答案 3 :(得分：1)
虽然从技术上讲这种方法会很好，但我个人不会使用SVN来存储这样的二进制文件。
我有两个原因，为什么会这样。 最初我认为SVN跟随CVS并且没有存储二进制差异，但事实证明我错了。无论如何：
0）“技术上”您不需要存储生成的文件，因为必要时可以重新生成它们。显然这在现实生活中是不实际的，但恕我直言，你仍然应该考虑“如何为生成的东西建立一个缓存。”
SVN并不适合该使用模式。这本身并不是真正的一点，但我想传达的是“在SVN中放置一些东西意味着你关心它并希望将其归档” - 如果你不这样做，你不应该恕我直言消息，隐含或其他
1）这很烦人。如果有人检查了您的仓库顶部，他们也会获得所有二进制文件。如果你有超过一两个兆，这将使人们不得不等待那些东西（并用尽他们的磁盘空间）没有充分的理由。这可以通过设置一个单独的存储库来解决，但是一旦你这样做了恕我直言，你可能只需要设置一个单独的网络服务器。
2）SVN旨在永久保存您的所有文件。 It is very painful and time consuming to completely remove things from the repository，这使得存储您不需要存储的内容存在疑问。
我建议您只使用网络服务器存储二进制文件。 （SVN毕竟是一个Web服务器**）。在服务器上保留尽可能多的旧二进制文件，并备份它，但是一旦你不再需要它们就可以删除旧的无用二进制文件。
**是的我知道它使用DAV，因此它不仅仅是一个普通的旧网络服务器，但从部署到生产机器的角度来看，过程是'我使用来自{{3}的http下载一些文件}'，所以它也可能是一个。
答案 4 :(得分：0)
不确定为什么你不想把二进制文件放在trunk / project1 / binaries树下？也就是说，没有什么能阻止你让树看起来像这样：
<tag id＆GT;
<code as usual＆GT;