最近部门为了提高工作效率，决定推行一系列规范化管理。其中之一就是版本控制。SVN作为近年逐渐兴起的新一代版本控制管理工具，加上开源的特点，当仁不让地成为我们的第一选择。

如何开展版本控制呢？刚开始的时候想得很简单。心想“我们只要搭建个SVN服务器，配置好权限。然后发一封邮件，大家肯定会一呼百应。毕竟这是会上领导重点提出的要求，再加上对他们有好处，可以提高工作效率，推广起来肯定是不费吹灰之力的”。可是做的往往没有想的那么容易。

挑战1：历史原因
客户的现有平台是90年代搭建起来的，使用的都是古老的技术，当时没有版本控制的概念。现在要重拾版本控制，谈何容易！光是上百个日常应用累都累死你，更不要说那些躺在角落九千年没人用的应用，有些连源代码都没有了！只有class文件。真想杀人！

挑战2：工作习惯
前面提到的客户的现有平台如此混乱，其中一个最大的原因就是平时没有养成版本控制的习惯。对程序的版本控制就是简单的拷贝-->复制-->加上日期重命名。所以在一个项目下可以看到几十个带时间的备份文件，或者诸如bak1，bak2之类惨不忍睹的文件名。

这些人由于平时松散惯了，你现在突然要改变他们的工作习惯和方式，他们会不自主地产生一种“消极对待或抵抗”的情绪。之前没有版本控制不也是过来了，搞什么版本控制嘛？所以说项目管理中最大的成本是什么：是人；最耗时的改变是什么：改变人的工作方式和习惯。要强行推行一种技术不难，但要改变一个人的习惯很难。

由于这种潜意识里的抵抗情绪，所以客户同事会用各种理由来阻止使用版本控制。比如说IDE不兼容啊，操作麻烦啊。

挑战3：误解
在当初部门会议上提出推行版本控制的时候，我就知道肯定会有些人事会对我们有意见，认为我们是为了出风头或控制大权而故意推行的。果不其然过几天后就开始有些同事说一些酸溜溜的话。如果没有足够的心里的准备，这个时候的打击是很大的。

挑战4：经验
由于整个部门之前没有任何版本控制的正规经验，所以我和另外一个同事都是摸着石头过河，不能拿生产环境下手，什么事情都得在自己技巧上，测试机器上测试通过，确保万无一失才敢部署上服务器。期间我们遇到了很多琐碎的问题，有些虽然小却足以浪费你一个下午的时间。

一个负责SVN同事面对这种情况，一开始有点落差，显得有点恨铁不成钢的感觉。我向他解析：别看现在我们是装个工具，配置下权限。其实事件的深层次是我们要改变他们熟悉的工作方式和习惯。让他们有了一种受威胁的感觉，从而产生抗拒感。这是人的一种本能，是对事不对人的。我们只能一步步来，慢慢地过渡。

方法1：加大宣传
针对部门平时的工作情况，我们找出了由于不使用版本控制而带来的一系列麻烦。因为这些麻烦多数人都遇到，所以在谈到这些问题时首先已经击中他们的要害。通过培训，交谈等方式重点宣传使用SVN的好处，只有让客户感到有好处我们才能继续开展下去。

方法2：主动出击
刚开始我们几个同事部署好了SVN，却没有人愿意使用，这确实很打击我们的士气。于是我们决定主动出击，主动发邮件通知大家，邀请大家以尝试的方式先把项目放到我们的版本库进行控制，并承诺对出现的问题，在力所能及的范围内我们都会尽快解决，这样很快有了“第一个客户”。

方法3：曲线救国
很多同事一开始对版本控制并不感冒，好既然我正面说不动你，那我就来个曲线救国，釜底抽薪：我先说服客户，让客户同意从SVN中check out/in代码，而不从其它途径获取代码；或者我直接找上级领导，以行政命令的方式代替日常的说服，这样就断了他们的后路，你不用版本控制也不行了。

不过我不喜欢这种方式，至今也没有使用这种方式。因为这是一种半强迫式的做法。是失败的管理者采用的粗暴简单手段。俗话说：攻城为下，攻心为上。不让同事客户明白使用SVN的好处，他们是不会真正配合的。我还是会坚持上面的两种方法的。

方法4：操作便利
任何一项工具或服务，假如没有提供便利的操作，哪怕好处说破天也不会有人用。没人会因为技术而技术。所以我们在推广SVN的时候，除了注意强调SVN的好处，还必须注意如何为同事，客户提供最便利的操作服务。因为我们开发小组和客户一个处于广州，一个处于香港，网络不同。客户出于安全考虑不愿通过普通公网访问我们版本库，但如果版本库建在客户处，我们又经常需要以VPN的方式登陆然后check in/out，这在大数据量的check in/out时非常缓慢而且会断开原来的网络连接，用户体验很差。

针对这种情况我们将会采用Apache + SVN构建SSL的方式，提供加密方式的SVN连接。即免去客户的顾虑，也免除我们同事使用的麻烦。更可以脱离公司内网的限制随时随地进行版本控制。

通过最近这些日子的工作，我深深地体会到项目管理的难处，这种难处很多时候比写不出程序更打击人，但更有挑战性和学习意义。版本控制之路，路漫漫其修远兮，吾将上下而求索。