将svn用于文档是否可行

Question

我们需要在客户端之间共享文档（类似CRM的功能）。用户需要能够：

• 编辑文档并再次保存
• 附加新文件

我们的应用程序在WPF中编码，WCF用于数据传输，NHibernate / SQL用于服务器上的数据。

我们正在考虑的是使用SVN并让应用程序创建存储库部分的本地签出（当他们单击文档时，SVN在后台检出并从本地路径打开） - 保存后，它将以静默方式（使用路径监控）提交回存储库。

问题：这是否可行 - 或者有更好的解决方案吗？

编辑1： 总结到目前为止：

• 我将研究使用Git / Mercurial而不是SVN
• 文档大小（修订版）可能会等待测试
• SharePoint是一个选项（虽然在我的情况下不可行，因为单独的成本是令人望而却步的） - 我将研究SharePoint的替代品，等等。
• 虽然适用于小型团队，但对于许多用户使用存储库的经验并不多。
• Wiki软件可能是SVN的替代品。

感谢所有反馈 - 我会保持更长时间。

编辑2： 工作几天后的总结 - 我有一个客户工作 - 看我的进度here。

Answer 1

基于繁重的.NET引用，您是否都设置了MSDN？也许您可以使用SharePoint ...它可能已经包含在您的MSDN帐户中。

Answer 2

您可能还想考虑使用Wiki进行文档管理 - 我已经看到这样做了，并为我自己的组织自己做。我们正在使用Atlassian的Confluence Wiki。 Confluence提供文档的版本控制和一般管理。

Answer 3

我不会使用SVN，SVN在处理二进制文件时效率不高。通过使用SVN作为应用程序中某些内容的反向通道，您只需通过添加其他技术和依赖项来复杂化，但您不会充分发挥其实际潜力。

我会将文档作为blob存储在数据库中，并通过WCF获取/存储它们。

Answer 4

通常我不认为SVN或任何版本控制系统用于共享文档是一件好事。主要的缺点是二进制文件上的差异系统...你的SVN仓库会迅速增长..

也许你应该尝试使用一些专为文档共享而设计的商业工具（例如Microsoft Sharepoint）。或者一些开源替代品......也许你应该阅读这个post ...

Answer 5

我认为使用现成的和经过验证的技术是个好主意。如果你真的这么做，我想看看它的进展。

我强烈要求反对SharePoint - 你会以这里难以描述的方式将自己与微软联系起来。从我的角度来看，SharePoint是一种需要自己照顾的技术。

Answer 6

这取决于您使用的文档类型。如果您有大量更改的压缩二进制文件，请不要使用它。

但是，如果文档是开放格式，如Wiki语言，（X）HTML，LaTeX或未压缩的ODF，那么使用版本控制系统绝对有意义。此外，一堆压缩的ODF文件或PDF文件处理得非常好，特别是如果文件大多小于5 MB左右。

此外，在坚持概念过时的SVN之前，请务必检查一些更新的版本控制系统，如 Mercurial 和 Git 。在你的场景中，你不会从Mercurial和Git的“分布式”部分获得太多利润，但它们更容易设置 - 至少根据我的经验。它们提供了非常先进的版本控制功能，可以在极少数情况下在您需要时节省您的一天。

如果您坚持使用SVN，并且您的客户端软件在现代Unix系统下运行，您也可以尝试 SVN-FS 。这是一个使用远程SVN服务器的文件系统。每次阅读都会进入最新版本。每次写入都会创建一个新提交。这似乎正是你想围绕SVN构建的。