//软件的版本控制问题，从有软件开发的概念开始，就是一个问题。随着大规模的团队开发的增多，版本管理和控制问题变得迫切和重要起来。所以，软件的版本控制问题一开始并不是用软件来管理的，今后也不一定非要用软件来管理软件开发。但是：使用版本控制软件的确是大势所趋，已经几乎是一个绕不过去的问题了。
//版本控制软件目前很多，而流行的是 CVS 和 SVN，SVN 是后起之秀，有取代 CVS 的趋势。
//版本控制的错误意识之一：一个人的微型软件作坊，用不上版本控制软件。
解释：版本控制的概念自然是绕不过去的，而版本控制软件完全可以不用。但是：1，版本控制软件一个人是完全可以用的，不是非得在团队开发时才想起它；2，即使是一个人开发软件，使用版本控制软件来管理代码，也会带来很大的益处。
//版本控制的错误意识之二：版本控制系统只能建构在独立的一台机器上。
解释：目前流行的 CVS 和 SVN 版本管理系统，的确主要应用在 C/S 模式下，但并不是不能用浏览器来管理，例如 SVN 就可以通过 Webdav 协议来远程管理 www 服务方式的 SVN，更可以通过浏览器直接浏览版本库里的内容。
但是，即使是这样，也不是说，版本控制系统必须/一定/只能建构在独立的一台机器上。实际上：
1，版本控制库完全可以建立在自己的机器上（本地版本库），然后自己用。
2，建立版本控制系统，也不是必须使用专门的 SVN Server 软件，现在的“乌龟SVN客户端”既可以作为客户端与 SVN Server（例如 VisualSVN Server）配合，它自己也可以提供服务，从而建立一个完全功能的、本地管理的版本控制系统。
//版本控制的错误意识之三：有了版本控制软件，就不会出现版本问题。
解释：绝对不是！正是因为版本控制问题太复杂了，才引入版本控制软件来辅助管理。注意，我这里说的是“辅助”！因为人永远是软件开发和管理这种生产活动中最重要和最具能动性的因素，软件永远都是人的奴才和工具。
注意版本管理软件能且只能管理和协调文本级别的代码问题，例如冲突、合并、更新等等，纠正程序逻辑错误根本不是它的事情！这意味着，即使团队里所有人和“SVN”都认可你写的代码，但这些代码导出后发行到客户手里，也不见得是可用的。
//版本控制的错误意识之四：有了版本控制软件，软件团队里的程序员就不用花时间交流了。
解释：错！版本控制软件永远代替不了交流，况且交流往往是逻辑和业务层面的，这些事情版本管理软件根本无能为力。事实上，即使在版本控制系统的管理下，程序员也需要在部分代码修改后，尽量想法通知别的程序员，而不是全部依赖版本控制系统的日志，这样将减少解决代码文本冲突的机会。解决版本冲突是版本控制系统最重要和复杂的功能之一，它能辅助我们解决问题，但最终解决问题的是人，而这需要时间和人的沟通，也就是说，需要耗费成本。
//版本控制的伎俩之一：并不是工程中所有的文件都必须和需要纳入版本控制中。那些不需要程序员控制和管理的软件测试中的数据文件等等，数量很大，字节数也很大，纳入版本控制系统中，没必要，也不允许。
//小知识之一：为什么使用版本管理软件
1，你是否在一个团队中工作？
2，是否发生过这样的情况: 当你在修改一个文件时，其他人也在修改这个文件？而你是否因此丢失过自己所作的修改呢？
3，是否曾经保存完一个修改，然后又想把个文件恢复到修改以前的状态？是否曾经希望能够看到一个文件以前某个时间点的状态？
4，是否曾经在项目中发现了一个 BUG，然后想调查它是什么时候产生的？
如果以上问题中的任何一个回答“是”的话，那么就有必要使用版本管理软件了。
//小知识之二：有人说：SVN 管理客户端就是 Tortoise SVN 软件，是不是？
这话偏了。说“乌龟SVN客户端是SVN管理客户端”是对的，反推回来的结论是不对的，因为 SVN 管理客户端很多，“乌龟”只是很流行的一种（当然很优秀了）。实际上，如果有必要和可能，你也可以开发一个你自己的 SVN 客户端来，问题是：有必要吗？你能吗？
本文转自网眼51CTO博客，原文链接：http://blog.51cto.com/itwatch/286607，如需转载请自行联系原作者
