版本控制与初识SVN（Subversion）

    至今为止，工作让我无比头痛的一件事就是程序的版本控制问题。

    目前我正在参与的项目所使用的版本控制工具是VSS。我从没有深入研究过什么版本控制工具，对VSS的认识也仅仅是在使用的时候才知道他的一些基本功能。

    就我看来，VSS使用的版本控制机制是“锁定-修改-解锁”的模式。本来，理论上说这也是一个很有效的版本控制方式，按照常理来讲，这样的独占式资源管理 应该可以起到避免多人同时处理同一个文件而带来的代码混乱问题。然而，实际情况却是，当几个人需要不得不同时处理同一个一个文件的时候，所有人都在担惊受 怕，或者一个人编辑，其他人忍受等待的时间，或者保持一个人签出文件，所有人都在本地修改，然后占有文件的人签入修改过的文件后，其他人在轮流合并文件， 这时候，每个需要合并文件的人都需要事先把自己改好的版本备份出来，再签出新版本，合并，签入。这样复杂而耗时的过程简直让人痛不欲生。

    由于个人使用的是NetBeans的IDE，其中自带了版本控制的集成支持，是名为“Subversion”的一个版本控制系统，于是抱着试试看的心态下 载了相关客户端和服务器端。事实上，经过实践，由于NetBeans的集成支持，只需要下载安装服务器端就可以了。

    起步很不顺手，或者说困难重重。我不得不面对一个完全陌生的软件，无人指导，并且最让我郁闷的是，作为一个通用的服务器端版本控制服务器，这个软件使用命令行进行控制……

 

 

---

 

    过了这么久了，终于有一个项目是使用SVN进行版本控制了。说说使用体会吧，事实上实在是没有时间仔细研究。

 

    虽说SVN是使用命令行的方式进行版本控制的，但是可喜的是现在市面上有很多SVN图形界面工具，用的比较广泛的就是Turtoise，非常好用并且是免费的SVN版本控制工具。

    经过一段时间的使用和考察，SVN实际上也是存在一个版本库的，版本库存放在服务器的指定路径中。客户端会将通过SVN传送到服务器版本库的所有文件，在 服务器端做版本登记，而从客户端本地上传的文件以及从服务器端获取（Check Out）的文件也都会在本地响应的留下版本记录，SVN的客户端将监视这些文件的变更，通过SVN在本地生成的版本控制文件，将本地文件副本与服务器的版 本资料库进行关联，并使用版本比较工具实施版本比较，实现版本控制的目的。

   例如，当本地修改了一个已经存在于服务器的文件——对于这样的本地文件我们称之为副本——的时候，SVN会判断文件已修改并更改版本控制文件，表示当前文 件已经与服务器端程序不一致，并且比服务器版本库的文件要新，当需要向服务器提交修改时，SVN会将此文件显示为更改，并自动更新修改过的内容。