我们在与客户的几个项目中尝试了Subversion。 它比我所希望的更好，但也有一些毛病。
背景：
目前的解决scheme是在我们的一个Web服务器上使用Subversion版本库。 他们安装TortoiseSVN，如果他们需要更新文件，否则他们使用bat文件调用命令行客户端。
由于我们引入了Subversion，所以我们在安装不同步的时候没有任何问题。 我们也可以跟踪一些搞砸的设置（并找出为什么发生）。
问题：
偶尔你会发生冲突。 主要是因为新手用户错误地改变了其中一个设置。 是否有一个svn客户端，可以很容易地解决新手用户的冲突？
（其中一家公司目前的解决scheme是删除整个安装并执行新的结帐）
编辑：该项目通常是我们的标准应用程序的定制版本。 客户位置的用户数量是2-10。
在这些情况下，svn export是您的朋友，它提供了代码的“干净”快照。 我的build议是以这种方式进行testing和生产。 这将帮助您find提交问题，如错过签入或冲突，因为您只是获取特定修订的文件。
为了防止出现这些问题，尤其是在使用svn时，请尝试使用生产分支。 生产部门由一位经验丰富的开发人员维护，他们可以使用多路diff工具从开发人员的分支中获取更改。 正如其他人指出的那样，svn merge（甚至更新）可能会容易出错，所以这个工作stream程允许select性地合并更改，这就是dscm（如Richard所描述的）的工作方式。
我对Subversion的一个看法是，它把所有的东西都看作是一系列的版本，其他的版本控制系统，比如Mercurial，看着变更集（就像最新的Stack Overflow Podcast中提到的那样）。 Subversion的这个方面让合并变得非常困难，因为它不知道发生了什么变化。
作为一个解决scheme，这是不是比你目前的解决scheme好多了，我会build议运行svn恢复到更新之前重置安装。
关于结帐和导出的好处在于，您可以看到在签出副本上工作的用户所做的更改。
如果你想要一个自动化的解决scheme，你可以让你的部署脚本使用svn diff将一些更改副本保存到某个位置（或通过电子邮件发送给你），然后在更新之前进行恢复。