非版本化 SVN 目录？
我们遇到的问题是客户向我们提供了要包含在版本中的内容，其中包括大量视频文件。他们的内容通常保存在 SVN 中，但由于他们无权访问它，因此对这些大型二进制文件进行版本控制似乎不太适合 SVN。我们的测试不需要这些文件（我们只需测试是否可以启动视频（如果找到）），并且我们不负责检查/测试客户提供的内容。
所以我想知道是否有可能有一个没有版本控制的 SVN 目录，而只是一个常规目录，在更新/签出时仍然可以拉取？ 或者也许 SVN 有办法从非 SVN 源提取文件，有点像 svn:externals 但不查看另一个存储库？
是否有 SVN 解决方案来解决这个问题，或者如果我们想避免对文件进行版本控制，我们是否应该简单地将它们放在另一个存储中并配置构建/部署脚本来单独拉取它们？
The issue we have is a customer supplies us with content to include in releases, and this includes a lot of video files. Their content generally goes in SVN but since they don't have access to it, versioning these large binary files doesn't really seem to fit SVN well. Our testing doesn't require these files (we just have to test we can launch a video if it's found) and we aren't responsible for checking/testing the customer's supplied content.
So I wondered if it's possible to have a SVN dir which isn't versioned, and is just a regular directory which can still be pulled when updating/checking-out?
Or maybe SVN has a way to pull files from a non-SVN source, somewhat like svn:externals but not looking at another repo?
Is there a SVN solution to this, or if we want to avoid versioning the files should we simply put them in another store and configure a build/deploy script to pull them separately?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
唉，不，subversion 存储提交给它的所有版本 - 没有设置标志来告诉它只保留最后一个版本。也许有一天，在obliterate实施后，但不要屏住呼吸等待:)
基本上，没有SVN解决方案来解决这个问题——所以你需要看看文档管理服务器，或者只是一个单独的文件存储。
不过，有一个选项可能适合您，如果您使用 TortoiseSvn，则可以使用其 客户端挂钩，自动将视频文件从文件存储拉取到本地系统。
全颠覆解决方案的替代方案是像平常一样将视频文件存储在其中，但然后定期转储/过滤/加载存储库以清除旧版本。如果视频文件非常大，这可能需要一些时间，所以我不确定是否推荐它，但如果您将它们存储在自己的存储库中，您只需获取最新版本，删除整个存储库，然后重新导入您刚刚需要使用 1 版本重新初始化存储库的文件。节省空间，并且可以编写脚本，但与只是告诉每个人“将视频文件从“\server\videos”中取出”相比，可能不值得这么麻烦。
Alas no, subversion stores all versions committed to it - there's no flag to set to tell it to keep just the last version. Maybe one day after obliterate is implemented, but don't hold your breath waiting for that :)
Basically, there isn't a SVN solution to this - so you need to look at a document-management server, or just a separate file store.
There is one option that might work for you though, if you use TortoiseSvn, you can use its client-side hooks to automatically pull the video files from the file store to the local system.
The alternative for an all-subversion solution is to store your video files in it as normal, but then regularly dump/filter/load the repository to clean out the old versions. this can take some time if the video files are very large so I'm not sure if I recommend it, but if you stored them in their own repo, you could simply get the latest version, delete the entire repo, and re-import the file you just got to re-initialise the repo with 1 version. Saves space, and could be scripted, but probably isn't worth the hassle comapred to just telling everyone "get your video files off "\server\videos".
问题是您的客户端和 SVN 存储库之间的桥梁，还是二进制文件的版本控制？
对于第二点，我认为没什么大不了的。从这里阅读：http://help.collab.net/index。 jsp?topic=/faq/svnbinary.html
由于在更新/提交小更改时，大文件的版本控制对于开发人员来说可能很粗鲁，因此您可以使用一系列专用的分支。
Is the problem the bridge between your client and the SVN repo, or the versioning of binary files ?
For the second one, I think there's no big deal. Read from here : http://help.collab.net/index.jsp?topic=/faq/svnbinary.html
Since versioning of big files can be rude for developers when updating/committing small changes, you can use a dedicated series of branches.
我不知道我的理解是否正确，但据我了解，您正在将代码与客户的巨大二进制文件隔离。
这又如何呢，
为您的大文件设置单独的专用 SVN 存储库。
仅授予客户对该存储库的访问权限。
使用 svn:externals 将这些文件拉入您的代码树中。
SVN 确实可以很好地处理大型二进制文件，如果您将它们放在单独的存储库中，它们不会污染您的代码存储库。
I don't know if I got you right but as far as I've understood it you are after isolation between your code and your customer's huge binary files.
What about this,
Set up a separate dedicated SVN repository for your large files.
Grant the customer access only to that repository.
Use the svn:externals to pull these files into your code tree.
SVN do handle large binary files pretty well and if you put them in a separate repo they won't pollute your code repo.