Subversion提供：
版本化的目录
    CVS只记录单个文件的历史，但是Subversion实现了一个可以跟踪目录树更改的“虚拟”版本化文件系统，文件和目录都是有版本的。
真实的版本历史
    因为CVS只记录单个文件的版本，对于拷贝和改名—这些文件经常发生的操作，会改变一个目录的内容—在CVS中并不支持。在CVS里你也不可以用一个完全不同的文件覆盖原来的同名文件而又不继承原来文件的历史。通过Subversion，你可以对文件或是目录进行增加、拷贝和改名操作，也可以新增一个具有干净历史的文件。
原子提交
    一系列的改动，要么全部提交到版本库，要么一个也不提交，这样可以让用户构建一个所要提交修改的逻辑块，防止部分修改提交到版本库。
版本化的元数据
    每一个文件或目录都有一套属性—键和它们的值，你可以建立并存储任何键/值对，属性也是随时间的流逝而纳入版本控制的，很像文件的内容。
可选的网络层
    Subversion在版本库访问方面有一个抽象概念，利于人们去实现新的网络机制，Subversion可以作为一个扩展模块与Apache结合，这给了Subversion在稳定性和交互性方面很大的好处，可以直接使用服务器的特性—认证、授权和传输压缩等等。也有一个轻型的，单独运行的 Subversion服务，这个服务使用自己的协议可以轻松的用SSH封装。
一致的数据操作
    Subversion表示文件是建立在二进制文件区别算法基础上的，对于文本（可读）和二进制（不可读）文件具备一致的操作方式，两种类型的文件都压缩存放在版本库中，区别信息是在网络上双向传递的。
有效率的分支和标签
    分支与标签的代价不与工程的大小成比例，Subversion建立分支与标签时只是拷贝整个工程，使用了一种类似于硬链接的机制，因而这类操作通常只会花费很少并且相对固定的时间。
可修改性
    Subversion没有历史负担，它由一系列良好的共享C库实现，具有定义良好的API，这使得Subversion非常容易维护，可以轻易的用其他语言操作。

     以前自己写程序的时候, 经常碰到改名的问题, 比如java里面包名的改变之类, 一般都是删除原来的, 新建一个新的, 于是以前的版本历史便对应不起来了. 但是都是这样的, 也没办法, 麻木了. 可是, 无独有偶, 就在我几天前一个下午, 改了一个类的名称, 提交到SourceSafe, 然后, 继续更改, 中间提交了一两次, 一段时间后, 代码写错, 头脑发热, 疯按Ctrl+z, eclipse SourceSafe插件弹出来两个对话框, 看都没看, yes, 于是, 我不幸的发现我的版本回到改名以前了, 然而名称还是改后的, 再打开一看, 旧内容, 赶紧打开SourceSafe找… , 一个下午的工作没了, 记得当时我在教研室说: 我想跳楼!  然后, 坐下, 重写. 后来分析, 可能一个对话框提示我是否回到先前版本(改名前), 而另一个是说, 会将新版本全部删除.
     还有就是版本的问题, 当时整个系统拿给用户看的时候, 就有人说这个刚建的文件怎么版本是二十几呢, 当时因为自己还没开始看这方面的文档, 只是说这个我们程序方面可能判断错了, 可能从Svn Server中读出了错误的信息. 后来回南京开始写客户端的时候, 才发现原来本身就是这样, 理念差异. Svn中每一次提交, 整个配置库Revision加1, 一个文件更改后提交, 其父文件夹即祖先文件夹都要自增一. 这样, 就是说每一个Revision对应的是整个配置库, 所有目录结构变化, 文件更替都会在提交时刻产生记录, 而这不就是基线嘛, 天然形成. 于是可以对某一Revision时配置库的内容进行Copy, 形成Tag,  便可以记录系统的某一版本. 现在看, CVS中给单个文件加版本, 1, 2, 分支版本1.1, 其实也就只是一个数字, 现在用Revision替代, 区别也只是数字变得不连续而已, 但是历史信息记录的更为彻底. 于是在系统中, 我给他起了个名字: 修订号, 这样可以区别于版本, 这样, 如果再有人提上面那个问题就好回答啦.  另一个问题出来了: 如果Svn每一个Revision都可以看作是整个配置库在那时的镜像, 那岂不是要占用大量的硬盘空间? 这个我没研究过, 不过答案可以肯定的是, Svn开发的时候肯定考虑过这个问题, 而且肯定以一定的机制控制了. 估计相对于其他工具大一点, 但不会大太多.

    而我的客户端是基于 SvnKit 实现的, 实现途径是基于其中对Repository的直接交互的API, 这样实现起来较为方便, 而这也导致了在后面文件, 文件夹 Commit 的时候产生了问题, 这个后面再说. 参照几乎所有的Svn Client, 大差不差, 都会有一个显示配置库的文件系统的树形结构, 这个非做不可. 然后, 因为大多数人所熟悉的传统的工具文件后的版本号都是可以清晰的让用户得知文件的修订状况, 然而对于Svn的编号大多不太适应, 觉得不能直接看出来这个文件多少版了, 于是在界面的右上方, 我设置了历史信息, 表格结构, 其中自动显示文件树中所选目录或者文件的所有历史信息, 包括相关目录下路径的各种改变, 而当然用户可以选择对某版本进行检出. 界面右下方则是相应用户操作的回显.  因为时间关系, 只是实现最基本的功能.
    最初, 是这样一个想法, 采用Observer设计模式, 注册文件树和操作信息显示界面到Model, 然后注册历史信息显示到文件树选择事件, 这样, 确保历史信息的显示和操作信息回显独立于界面, 以及配置库中信息发生变化, 文件树如果选择的是显示最新配置库结构, 则自动刷新. 但最后实现的只有一个, 就是操作信息回显可以在Console, File, JTextArea中选择. 有时间重构一下代码, 完善一下.
    下来遇到的问题就是提交问题了, Svn对于工作区实现是在工作区生成许多隐藏文件夹 .svn, 用这个来确保文件检入提交时所需信息的获取. 而自己当初实现的时候是直接导出库中的文件结构, 在修改后提交时, 提交时所需的两个条件(原始版本, 修订号) 都没有. 最后权宜之计, 在导入或检出时, 自动在各个目录下生成 .svnbacc 文件夹, 里面再拷贝一份该目录下所有文件, 将修订日期改为一致. 这样提交时的问题解决了, 但总觉得这样做问题很大, 当然, 一般写代码嘛,  代码文件都比较小, 复制一份, 无所谓, 但是当有大量的文档时, 所额外占用的空间就太大了, 现在正在研究 .svn 中的信息, 寻找替代方法.
    因为是BS结构的, 无法实时监控用户在客户端的文件结构变动, 当文件结构变化, 会将目录改变文件或文件夹作为新的Item提交, 这样的话, 如果想完成这种工作, 就只能直接对配置库进行文件结构改变, 然后再导出. 这也算是遗憾啦.
    建立一个Tag文件夹, 将系统定版时对应修订号的项目文件夹Copy到Tag中, 形成系统版本, 实现了Copy功能, 这样, 应该可以满足基本使用了. 因为提交时采用的那种方法, 可能到时问题可能还很多, 不过目前也只能这样了.
    整个Applet是要进行签名才能够使用的, 要不会因为权限问题不能进行文件操作, 以及与Svn Server交互.
    签名方法以前写过:      Signed Applet

    下面是最近几天写Java Swing的一些代码总结, 以备日后之需.

使用Hashtable构造JTree: subTree作为参数传进,递归操作, 便可以将文件系统的树形结构构造出

 这样做的问题是不能即时更改树的某节点, 更改就得全部刷新重新执行造树操作.

    /*

     * if it is a directory, make a new tree, add it to subtree

     */ 

    Hashtable newTree = new Hashtable();

    subTree.put(entry.getName(), newTree);

    /*

     * if it is a file, add it to subtree

     */

    subTree.put(entry.getName(), "");

使用Vector构造JTable:

    /*

     * table column names.

     */

    Vector columnNames = new Vector();

    columnNames.add("修订号");

    columnNames.add("作者");

    columnNames.add("时间");

    columnNames.add("提交信息");

    columnNames.add("路径变化信息");

    /*

     *table data

     */

    Vector data = new Vector();

    for(int i=0; i<infos.length; i++) {    

        Vector item = new Vector();

        item.add(infos[i].getRevision());

        item.add(infos[i].getAuthor());

        item.add(infos[i].getDate().toString());

        item.add(infos[i].getLogMessages());

        item.add(infos[i].getChangePaths()[0]);

        data.add(item);

    }

    historyInfo_jTable = new JTable(data, columnNames);

    /*

     * set table column width. 

     */

    TableColumn column = null;        

    column = historyInfo_jTable.getColumnModel().getColumn(0);

    column.setPreferredWidth(10);    

通过JTree我们可以得到所选节点的路径, 但是是TreePath结构的, 下面方法转换其为url

/*

 * get url string from TreePath object.

 */

public static String getUrlFromTreePath(TreePath tp) {

    String url;

    url = tp.toString();

    url = url.substring(url.indexOf(",")+2, url.lastIndexOf("]"));

    url = url.replaceAll(", ", "/");    

    return url;        

}

通过TreePath判断树节点类型 ( MouseEvent e )

    TreePath treePath = repositoryInfo_jTree.getPathForLocation(e.getX(),e.getY());

    DefaultMutableTreeNode node = (DefaultMutableTreeNode)(

            treePath.getLastPathComponent());  

    if(!node.isLeaf())

        ...

    }

右键事件 MouseEvent e, 判断右键是否点在树节点上, 然后在该节点上显示右键菜单.

    /*

     * lock the pop up menu location to tree node.

     */

    Object nodeObj = repositoryInfo_jTree.getPathForLocation(e.getX(),e.getY()).getLastPathComponent();

    /*

     * if returns null, it means does not click the right mouse button on tree node. 

     */

    if(nodeObj != null)

        popMenu.show(repositoryInfo_jTree,e.getX(),e.getY());

     上星期天晚上无奈的背着包拉着要推销给总装的触摸屏, 跟一帮人上了开往北京的火车, 虽说是卧铺, 可是是上铺, 最便宜的, 空间极度狭小.
     忘了买水了, 幸好带了杯子, 跑去打水, 结果发现, 杯子不隔热, 烫的要命, 没办法, 不打了.
     等啊等, 等了很久才等到卖水的来, 极度郁闷, 在下面坐了会儿, 直接上床了, 跟上次去武汉的大巴差不多挤, 难受! 刚带上耳机, 准备睡觉. 对铺一哥们上来了, 偏偏就是跟大家反着睡, 那个脚, 就在我头旁边, 好臭呀…
     腰酸背痛的起来, 差不多到北京了.
     车站人多的一塌糊涂, 出站的时候不知被踩了多少脚. 外面人挤成一片, 那是人山人海, 众里寻她千百度, 终于找到了要接我们的军车, 上车就倒在后座了, 饿死啦.
     过了一二三四五环, 终于到了航天城, 本想可以到宾馆躺一躺, 结果领队的是一工作狂, 直接去办公室部署环境. 这不脸都没洗牙都没刷嘛, 没办法, 就去了. 中午吃了饭, 想睡一觉的愿望又泡汤了, 又去轨道室办公室部署项目去了.
      其实, 这个项目其实与自己没什么关系, 这不明摆着是去混吃混喝浪费青春去了嘛.
      程序出了许多问题, 自己就百无聊赖的站着, 看他们改程序, 时间到了就去吃饭, 无聊到了极点.
      估计人家看出了我们无事可做, 于是带我们去航天指控中心看了把, 又看了短片, 权当补偿了一下几天无聊的日子.
      老板也看出来了我是去混吃混喝的, 于是就干脆让我跟他们几个去市里转转, 老天可真对得起我, 阴了好几天, 就那天大晴天, 想热死我呗! 饿着肚子在天安门前找kfc, 奔向王府井找吃的, 郁闷!  跑到清华那边, 结果走错方向了, 跑到语言大学, 无奈!
       终于时间到了礼拜六, 回南京, 到车站竟还有两个小时车才开, 等呗, 然后, 坐着, 8个小时, 长途跋涉, 终于, 拖着疲倦的身躯回到了南京…

                                          啊, 出差到首都

       在教研室吃完了qfgu买的西瓜之后, 一行人浩浩荡荡的往西门去了, 打的到火车站, 去北京. 而且买得是特快卧铺, 应该睡一觉就到了. 只是票很紧张, 是上铺. 虽然空间比较小, 但好歹可以躺着睡觉呀.
       潜意识以为这次出差跟去上海一样, 什么也没准备, 上车才醒悟是长途呀, 没带水和吃的, 所幸自己还带了杯子, 于是去打开水, 破杯子, 不隔热, 没办法, 等卖水的来呗.
       于是, 坐在下面等, 跟同行的人不时搭话, 这一直是我在长途车上最好的度日方法, 也是一种享受.
       买了水, 决定上床躺着, 不错, 虽空间小, 但躺着还是蛮舒服的, 带上耳机, 听歌. 一股脚臭味飘了过来, 原来对铺的一哥们上来了, 脚朝着我.  幸运的是, 大概半个小时候, 他脚和头调了个外置, 我沉睡了过去…
       一觉起来, 买了桶方便面吃了, 到北京了.
       首都就是首都, 人就是多. 拼命找接我们的车, 终于找到了, 一看是白牌子, 哈哈, 生平第一次坐军车, 虽然当时很饿, 但初到北京的新鲜感使得自己兴奋得拿着手机不时对着外面的建筑物拍照.
       上了高速, 一会儿, 到了航天城, 军人就是军人, 我们一去就雷厉风行的跟他们去办公室部署环境, 当时又累又饿. 还好, 不久就奔向宾馆吃午饭, 35块的自助, 不错不错, 撑死了. 吃完饭和ct又直接去办公室了, 累归累, 但好歹肚子填饱啦.
       虽然这个项目与自己关系不大, 但是既然去了, 也学习学习人家军队的制度嘛.
       程序出了很多问题, 边测边改, 人民解放军就是亲民, 态度极好, 处处为我们着想, 有时候明明是我们的问题, 但他们说: 这个也可以用, 只是不方便而已, 先用嘛, 以后再说. 感动ing.
       中间还带我们去了趟指控中心, 一直在电视上看到的神五神六指控中心大厅, 自己却处身其中, 极度兴奋, 大三时候参观过试飞院飞机飞行监控中心, 这次是航天指控中心, 不枉此生啊!
        老板又特批我们一天假, 让我们去长安街逛逛, 第一次亲眼看到天安门, 走在王府井大街上, 站在MS和Google楼旁…  虽然日头很猛, 热的快要中暑, 累的快要趴下, 但心情依然极为兴奋!
        时间眨眼到了礼拜六, 吃完最后一顿丰盛的自助早餐, 坐上军车, 去了火车站, 开始还怕赶不到, 结果早了很长时间, 候车室打了几局牌. 坐上了回南京的动车组, 虽说坐了8个小时, 蛮累的, 但是动车组就是速度快, 体验了一下200多的速度, 值了.  

           其实有时候快乐与痛苦仅一步之遥, 同样的事情, 不同的对待方法带来的心情也许会截然相反, 当然, 我们不可能使自己永远快乐, 但快乐多一点, 其实有时候, 很简单…

            P.S.   一直觉得军队的保密安全制度应该很健全, 信息系统应该都是可靠的安全的. 航天城那边也算是国家总装备部的, 一进去就感到戒备森严, 而且听说, 警卫甚至跟那边的员工不是一个部队的. 在办公室(他们说他们工作的地方是在指控中心大厅,办公室是用来看书做文档学习的地方), 贴着秘密的电脑(他们说是所谓的秘密), 我问道: 你们这边的杀毒软件是正版的吧. 对方含糊的说了一句: 这也不一定, 我们这边不一定用的都是正版软件. 的确, 其实这边用盗版, 谁敢说!  他们腾了几台机器给我们用, 是随便用, 当然U盘之类是不能插的. 但一些文档我们是可以看到的呀, 咱的嫦娥计划, 那边到处是倒计时. 而且我们的系统拷进去了以后, 还在不停修改, 感谢解放军对我们的信任, 很放心我们绝对不会也不敢在系统中安插一些病毒之类的东西.  下来就是大楼的警卫, 第一次去很凶, 像审犯人一样跟我们说话, 三四天后, 问: 哪的?  答: 南航的  然后一挥手, 进吧, 竟然免登记.  再来就是整个航天城的大门, 我们打电话给里面的宾馆, 说是哪个房间的, 然后把电话交给警卫, 前台服务员跟警卫说了一下, 放行. 记得去年在上海通用, 要进去, 先登记, 然后要找的人亲自过来接, 打电话是不行的. 看来外企极度不厚道呀?!
            我们当众演示系统的时候, 那边软件室的人也提了不少意见, 一些功能不好用之类的问题, 领导直接说, 能用就行. 我们当然很Happy呀. 一些人也提了不少听起来很好的意见, 然后最后都是一句话: 当然我说的不一定一定要这样做, 这样更改, 一切要我们领导说了算. 觉得给军队做项目就是舒服, 对我们又好, 刁钻的要求几乎没有. 但是毕竟用的人又不是领导, 万一领导不熟悉那个方面, 瞎指挥一通, 那用的人岂不难受!
            en, you dian chang la. OVER! 
                          

Who am i? This is the side of me!