如果开发计算机上安装了Subversion，但我们没有团队合作，那么有什么理由应该使用svn协议而不是文件？

解决方案

回答

我将svn：//用于个人项目，因为我经常在同一网络上的多台计算机上工作，并且希望将所有内容存储在台式机上的存储库中。

回答

我不知道是否。它应该证明至少要快一点。

回答

即使我自己工作……我的协议是即使对于个人项目也要始终使用源代码控制。它为所有代码工作提供了一个单一的备份点，并允许我们改变主意和/或者检索较旧的版本。

回答

如果我们是自己在单台机器上工作，那么以我的经验，使用file：//协议可以很好地工作。即使当我的团队在远程服务器上使用Subversion时，我也会为自己的个人项目建立一个基于文件的本地存储库。如果到达需要从另一台机器访问它的地步，那么我将麻烦设置基于服务器的存储库。我们可能还会看到像Mercurial这样的分布式系统，我们在我离开之前在上一家公司对它进行了评估，但肯定会选择其中一个，混合使用svn和hg根本无法正常工作。

回答

前一个项目，我们使用ant进行构建。 Ant将从SVN存储库中检出最新代码，进行构建，然后在SVN存储库中创建构建所基于的代码的标记。我们发现，除了svn：//协议之外，Ant自动化无法跨任何协议使用。

因此，如果我们想使用Ant来自动化与SVN的任何交互，则需要使用svn：//协议。

回答

我们以后总是可以添加一个Subversion服务器，使其指向file：//存储库，我们将立即获得svn：//的访问权限。

该协议无关紧要，它只允许通过不同类型的介质进行传输，重要的是存储库内容。

以后安装SVNSERVE相当容易。

但是，我们所使用的Subversion软件的风格确实很重要，例如，一个供应商做到了，因此元数据存储在" _svn"而不是" .svn"中，我们可能首先要检查兼容性。

回答

从来没听说过。使用源代码控制总是值得的，因此即使file：//在某种程度上逊色，如果这意味着我们实际上使用了subversion而不是受够了设置并开始进行编码，那么我的书就可以了。

回答

我使用的机器很多，因此对路径使用svn：//更容易。除此之外，我发现svn路径几乎总是比文件路径短，因此键入起来少。

回答

我相信，只要启用了相关SVN工具的使用，我们就不会像其他人所说的那样有问题，我们以后可以随时设置服务器。

然后，我的技巧是确保可以使用ToroiseSVN和Collabnet颠覆客户端。

如果我们愿意，现在可以简化SVN服务器设置的一个主要技巧是使用虚拟设备。也就是说，已经预先安装了Subversion并且(大多数情况下)预先配置了Subversion的虚拟机几乎是一个即插即用的东西。我们可以在这里，这里和这里尝试，也可以尝试在" Subversion Virtual Appliance"上搜索Google。

回答

选择file协议而不是基于服务器的协议的三个原因。

• 减少网络流量。

在不在工作站上的存储库中使用文件协议时，将写入整个文件，因为在没有守护进程来处理它们的情况下，无法使用增量。

• 我们可以通过Internet公开基于服务器的协议

这给我们留下了要使用svn还是http协议的问题。两者都可以通过网络使用。 Svn具有使用直接二进制而不是base64编码的效率优势。面对官僚主义的阻碍，" Http"更容易通过公司防火墙走私。

• 在跨域方案(例如，远程通勤)中，拥有权限的麻烦更少。

家庭工作站可能不属于公司域。 Subversion服务器守护程序充当代理。它在经过身份验证的进程中运行，该进程具有代表我们执行I / O操作所需的权限。

回答

这里提到基于文件和基于服务器的存储库。如果我错了，请指正我，但是我对Subversion的理解是存储库是系统文件存储库还是Berkley DB存储库。实际上，区分文件/服务器的方式只是访问存储库的方式。也就是说，可以使用file：///协议直接在文件系统上访问同一数据库(签出，提交等)，或者使用ssh，svn服务器和/或者使用http代理通过Apache访问。