标签：mount 导致 因此 com 取消 set 服务 版本号 tor
贴上一篇旧文，2013-08-06 我发表在部门周刊上的，一晃都五年多了~
当时是看完 svn cookbook 后写的，满满的翻译腔，哈哈~~
作为码农，版本控制工具SVN是我们最常用的软件之一。
可是，仔细想想，除了svn update，svn commit，svn log，svn diff，你还知道什么？
当然，这几个命令已经足以满足我们80%的需求。
然而，总有几个问题，让你泪流满面，总有一种力量，让你前行。
通过一些工作中遇到的场景，本文将为你介绍一下那些你不了解却能在关键时刻救你于水火的SVN命令。
TortoiseSVN并不等同于SVN。
在安装TortoiseSVN时勾选“安装命令行”，本文内容在windows下亦有效。
首先，问题的根源在于目录结构划分的不合理。在你解决这个问题之前，你可以使用其它方法来回避。
svn update --set-depth exclude biiiiigFolder
这将会更新除了 biiiiigFolder 以外的其他目录。下次你只需使用svn update即可。
取消这种设定，使用
svn update --set-depth infinity
如果出现这种情况，你很可能编译出一个不是你想要的版本，进而可能给你带来一些未知的、莫名其妙的bug，浪费你的时间。一个简单的命令将会解决这个问题。
svn status
它将会列出文件或目录的状态，如果状态为M，则代表它被修改了。
接下来，你可以使用
svn diff filename
来查看这些修改是不是你想要的，然后使用
svn revert filename
来还原那些你不想修改的文件。
有趣的是，这三个命令都可以在没有网络的情况下工作。
事实上，svn update已经足够了，你只需要再加上一个参数。
svn update –r 123
这样的场景想想都让人抓狂，幸运的是，你不必这样做。
svn diff –r 101:1001 omg.cpp
什么感觉？恍然大悟+不过如此？如果你在windows下设置了外部比较工具，
SET DIFF3="C:\Program Files\Funky Stuff\My Merge Tool.exe"
上述命令将会给你带来足够的惊喜。
导致这种情况的原因有多个，常见的有两种：
（1）这份工作副本是你从其他人那里拷贝过来的，鉴权文件不一致——你不应该这样做，删除它自己check out吧。
（2）上次的SVN操作中断了，工作拷贝中遗留的日志文件中还有部分工作拷贝锁。这时只需使用清理命令即可。
svn cleanup
你可以从技术上暂时解决这个问题，但是你得知道这并不是个技术问题。
svn在设计上并不鼓励加锁，因此并非管理员才可以解除锁定，任何用户只需要使用
svn unlock –f filename
就可以打破锁定。你甚至可以使用
svn lock –f filename
来窃取锁定。这个文件不再是被小明加锁而是被你加锁了。
然而，滥用锁定、打破锁定、窃取锁定将会打开潘多拉的魔盒，你不应该轻易使用这三个命令中的任何一个。
svn的版本控制模型不是“锁定-修改-解锁”，而是“拷贝-修改-合并”。
svn保留了加锁-解锁机制是为了使其也能应用于那些不能根据上下文合并的文件，比如一段视频、一副图纸。
对可以根据上下文合并的代码文件加锁，导致的一个显而易见的问题是造成用户等待，降低团队效率；
另一个问题更严重，一旦小明归并-解锁，几乎必然会导致其他人的工作拷贝冲突（如果不会冲突那为什么要加锁
呢），进而导致另其他人的工作白费。
如果你不想让自己的工作白费，就去打破锁定、窃取锁定，而这将导致小明的工作白费。
毫无疑问，滥用加锁将会使团队充满负能量。
说到最后，真正解决这个问题的办法是：加强团队沟通。
当团队缺乏沟通，语法和语义的冲突就会增加，没有系统可以强制用户完美的交流，没有系统可以检测语义上的冲
突，所以没有任何证据能够承诺锁定系统可以防止冲突。
一个可操作的方法是：如果文件修改不会和其他人冲突，那就不加锁，如果可以预见必然会产生冲突，你应该加锁
并通知其他人在你解除锁定之后再做修改。
标签：mount 导致 因此 com 取消 set 服务 版本号 tor
原文地址：https://www.cnblogs.com/parody/p/9937594.html
