如果您的开发计算机上安装了Subversion而您没有在团队中工作，那么您是否应该使用 svn 协议而不是文件 ？
答案 0 :(得分：8)
如果您在一台计算机上独立工作，那么根据我使用file：//协议的经验可以正常工作。即使我的团队在远程服务器上使用Subversion，我也会为自己的个人项目设置一个基于文件的本地存储库。如果你到了需要从另一台机器访问它的地步，那么我会遇到设置基于服务器的存储库的麻烦。您可能还会看到像Mercurial这样的分布式系统 - 我在离开之前就在我的上一家公司进行了评估 - 但是肯定会选择其中一种，混合svn和hg根本不能正常工作。
答案 1 :(得分：5)
您可以随时添加一个subversion服务器，让它指向您的文件：// repository，您将立即获得svn：// access。
协议没关系，它只允许在不同类型的媒体上传输，它是重要的存储库内容。
以后安装SVNSERVE相当容易。
然而，你使用的颠覆软件的味道确实很重要，例如一个供应商这样做，所以元数据存储在“_svn”而不是“.svn”，你可能想先检查兼容性。
答案 2 :(得分：2)
我相信只要启用相关SVN工具的使用，你应该没有问题 - 就像其他人说的那样，你可以随时设置服务器。
我的提示是确保您可以使用ToroiseSVN和Collabnet subversion客户端。
如果您愿意，现在可以轻松设置SVN服务器的一个主要提示是使用虚拟设备。也就是说，一个虚拟机预先安装了subversion并且（大部分）预先配置了它 - 几乎就是插件和插件。玩的东西。您可以尝试here，here和here，或者只是尝试在Google上搜索“颠覆虚拟设备”。
答案 3 :(得分：1)
回到一个项目，我们使用ant来做构建。 Ant会检查SVN repo中的最新代码，进行构建，然后在构建所基于的代码的SVN repo中创建一个标记。我们发现除了svn：//协议之外，Ant自动化无法跨任何协议工作。
因此，如果您想使用Ant自动执行与SVN的任何交互，则需要使用svn：//协议。
答案 4 :(得分：1)
不是我知道的。使用源代码控制总是值得的，所以即使file：//在某种程度上比较差，如果它意味着你实际上使用 subversion而不是厌倦了设置而只是开始编码，那么我的书好了。
答案 5 :(得分：1)
这里提到了基于文件和基于服务器的存储库。如果我错了，请纠正我，但我对Subversion的理解是存储库是系统文件存储库或Berkley DB存储库。正在进行的文件/服务器区别实际上就是访问存储库的方式。即，可以使用文件：///协议直接在文件系统上访问（检出，提交等）相同的存储库，或者使用ssh，svn服务器和/或带有http的Apache来访问相同的存储库。
答案 6 :(得分：0)
我将svn：//用于个人项目，因为我经常在同一网络上的多台计算机上工作，并且我想将所有内容存储在桌面计算机上的存储库中。
答案 7 :(得分：0)
我不知道是否。它应该证明至少是little bit faster。
答案 8 :(得分：0)
我有很多不同的机器，所以我更容易使用svn：//作为路径。除此之外，我发现svn路径几乎总是比我的文件路径短，所以输入的次数要少。
答案 9 :(得分：0)
通过file协议选择基于服务器的协议有三个原因。
当您在不在工作站上的存储库上使用文件协议时，会写入整个文件，因为在没有守护程序处理它们时，不能使用增量。
这使您无法使用svn或http协议。两者都可以通过网络使用。 Svn具有使用直接二进制而不是base64编码的效率优势。面对官僚主义的阻挠，Http更容易通过公司防火墙走私。
您的家庭工作站可能不属于公司域。 Subversion服务器守护程序用作代理。它在经过身份验证的进程中运行，该进程具有代表您执行I / O操作所需的权限。
答案 10 :(得分：0)
file://访问模式可以正常工作。此外，如果您需要与其他人协作，将存储库放在服务器上并通过https://或svn://使存储库可用时应该没有问题。
但是，file:// URL在Windows上很难看，使用HTTP（S）服务器可以帮助您使用漂亮的URL。 Windows上的典型本地URL看起来像file:///C:\Repositories\MyRepo。但是，我更喜欢https://svn.example.com/MyRepo。
答案 11 :(得分：-2)
即使自己工作......我的协议是始终使用源代码控制，即使是个人项目。它为您的所有代码工作提供单点备份，并允许您改变主意和/或检索旧版本。