背景
在Java世界，有个叫maven的东西，被成为 best idea in poor practise. 思想不错，但是用起来变得混乱。简单的说，maven负责代码版本的控制，而且的自动更新需要引用的代码等功能。
无论maven，或者maven2，我都觉得比较失败，主要有2点：
1. 代码版本管理应该是辅助管理，不应该越权去主动更新代码。这个要人去控制。比如svn等。否则，立马出现各种问题导致编译不通过。
2. 代码版本管理应该有权限，不能阿猫阿狗自己新建个项目就说是个新版本。现实中也看到了，maven导致了版本的混乱，而并没有解决他需要做的事情。
太过依赖xml去自动化，导致适得其反. 针对这个best idea，我提出自己的一个思路。
项目管理系统的思路
Introduction 简介
有一个中央服务器控制当前组织下的代码版本，形成全局唯一管理。
本地通过web service能够链接中央服务器，获取代码版本信息，修改项目的版本号等。
中央服务器有B/S去负责代码版本控制的权限操作等。
Terms 术语
Checkpoint 检查点
。对本地代码版本进行检查和提示。
。在本地设立一个检查点，能够查看当前检查点代码的版本、查看和检查点需要的版本之间的差别。
。例如，在客户化项目中，对“上海徐家汇xxx公司”作为一个检查点checkpoint，公司的部署人员在部署环境中，能够检查客户目前程序的版本是否符合部署最低要求等。
。checkpoint仅仅作为查看，没有任何操作的权限。
Workshop 工作室
。监控本地项目的引用的版本、控制本地项目的输出版本。
。例如目前“上海徐家汇xxx公司”的项目引用了我们公司xxx.dll类库,这个类库的版本必须高于3.0.12.x；每次对项目修改后，全局控制项目输出的版本号。
。workshop就是针对项目开发的版本控制。
Vision 愿景
1. 能够通过checkpoint检查当前的版本情况，并生成版本报告。
2. 能够通过workshop协助项目开发，管理项目引用类库的版本号。
3. 能够通过workshop控制项目发布的版本号，并编写全局唯一的版本号
4. 管理系统采用金字塔型的授权模式，并且所有用户使用唯一ID去识别，不允许出现等级循环。
5. 建立一个存在的workshop，自己负责。
6. 新建一个全新的workshop都需要上级授权，上级负责，因此杜绝了版本混乱。
Use Case Sample 用例简介
1. 建立一个checkpoint
。 【部署人员】在系统中，请求新建一个checkpoint
。 【部署人员】选择checkpoint的ID（之前已经建立的）
。 【部署人员】选择本地的项目路径
。 【部署人员】确认
。 【系统】自动链接服务器，获取当前checkpoint的类库版本列表
。 【系统】搜索本地项目路径，对比当前部署的版本号。
。 【系统】生成一个报表。
2. 建立一个存在workshop
。 【部署人员】在系统中，请求新建一个workshop
。 【部署人员】选择workshop的ID（之前已经建立的）
。 【部署人员】选择本地项目路径
。 【部署人员】选择本地项目引用的路径
。 【系统】链接远程服务器，获取项目的引用版本要求
。 【系统】搜索项目的版本控制文件（Assembly.cs）
。 【系统】在本地新建一个版本变动历史文件夹，开始记录版本变动日志
。 【系统】检查本地引用路径的类库是否符合引用要求
。 【系统】生成一个建立结果报表。
3. 编译项目，增加版本号
。 【部署人员】选择本地的workshop
。 【部署人员】在版本后面选择“增加”
。 【系统】下载服务器的最新版本号
。 【系统】上传修改后的版本号，再修改本地版本号