通过终端打开配置文件: open ~/.subversion/config
把下面两行(也可能是一行)中的注释和*.a去掉,
然后保存.
#global-ignores = *.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo  
#*.rej *~ #*# .#* .*.swp .DS_Store

注意：去掉#号后要顶行

或者在svn import 的时候加入参数 --no-ignore

SVN环境搭建完整步骤

1、SVN安装

从VM新建虚拟机

1）安装路径：D：\ubuntu-test

使用ubuntu 软件：c:\svn安装软件\ubuntu-10.04.1-desktop.i386.iso

Network adapter：Bridged

Ubuntu登录账号/密码：kiki/kiki

安装完成，重启ubuntu，打开terminal，自动获得了一个IP（172.28.6.13）。

2) 设置，安装过程

a) 设置 ip 和dns上网。

    Step1,

sudo –s 转成root用户，方便操作。

    Step2,

设置IP, vi /etc/network/interfaces

加入：

auto eth0

iface eth0 inet static

address 172.28.6.239

netmask 255.255.0.0

gateway 172.28.16.1

    Step3,

           Sudo nano /etc/resolv.conf

           是一个编辑工具，设置DNS。

           加入：nameserver 10.58.100.1

    Step4,

重新启动 networking 服务：

sudo /etc/init.d/networking restart

    总结：设置OK，ping 172.28.6.69成功。

b) apt-get update 先更新一下源。

c) 安装VIM

    apt-get install vim

d) 安装openssh-server

e)  安装subversion

f) 安装subversion-tools

g) 安装apache2

h) 安装libapache2-svn

i) 安装tree

j) 设置apache2下的SVN

       vim /etc/apache2/dav_svn.conf

       设置如下：

<Location /test/>

 DAV svn

  SVNListParentPath on

   SVNParentPath /home/repo/

  # SVNIndexXSLT "/apache2-default/svnindex.xsl" （注释掉，否则会有xml的错误，不能显示）

  AuthType Basic

  AuthName "Subversion Repository"

  AuthUserFile /etc/apache2/dav_svn.passwd

    Require valid-user

  AuthzSVNAccessFile /etc/apache2/dav_svn.authz  z居然泄露了，害我找了好久的原因

</Location>

PS：

1）刚安装好的apache2没有dav_svn.passwd文件，

使用vim 创建，

然后htpasswd -b dav_svn.passwd kiki kiki  更新密码。

创建dav_svn.auth文件，设置*=rw方便测试。

权限文件设置注意：[]*=rw,并且具备权限继承性，子目录的权限将代替父目录的权限。

2）创建测试所用的版本库，路径在：/home/repo/test1,其中test1是版本库。

3）重启apache服务  /etc/init.d/apache2 restart

4)  设置创建的帐户文件所属者为www-data.

设置创建的库所属者为www-data,

root@kiki-desktop:/etc/apache2# chown www-data:www-data dav_svn.passwd

root@kiki-desktop:/etc/apache2# chmod 777 dav_svn.passwd

root@kiki-desktop:/home# chown -R www-data:www-data repo

5）访问：http://IP/test/库名，SSH远程登录ubuntu出现中文乱码时，设置LANG=””;

2、SVN版本对比

2.1   Subversion 1.6的新东西

改进的认证数据处理

版本库根的相对URL

svn:externals的改进

目录树冲突的检测

文件系统存储改进

Ctypes Python绑定

改进的交互式冲突解决

稀疏目录的排除选项

svnserve的日志支持

察看历史的新HTTP URI语法

命令行客户端改进

API变更、改进以及多种语言绑定

超过65项新的bug修正和提升

参考：http://www.subversion.org.cn/?action-viewnews-itemid-99

2.2   以下为共进实际情况：

服务器：10.58.100.247 Subversion1.5

客户端：10.58.102.3    Subversion1.6

改进和bug修正

改进的交互式冲突解决(客户端)

svn up:

3、SVN备份

1. 10.58.101.6 截图：

2. 10.58.100.247 截图

2. 10.58.101.6截图：

1. Rsync（remote synchronize）是一个远程数据同步工具，可通过LAN/WAN快速同步多台主机间的文件。Rsync使用所谓的“Rsync算法”来使本地和远 程两个主机之间的文件达到同步，这个算法只传送两个文件的不同部分，而不是每次都整份传送，因此速度相当快。

第一次连通完成时，会把整份文件传输一次，以后则就只需进行增量备份。

2. Rsync支持大多数的类Unix系统，无论是Linux、Solaris还是BSD上都经过了良好的测试。此外，它在windows平台下也有相应的版 本，如cwRsync和Sync2NAS等工具。

3. Rsync的基本特点如下：

　　1.可以镜像保存整个目录树和文件系统；

　　2.可以很容易做到保持原来文件的权限、时间、软硬链接等；

　　3.无须特殊权限即可安装；

　　4.优化的流程，文件传输效率高；

　　5.可以使用rsh、ssh等方式来传输文件，当然也可以通过直接的socket连接；

6.支持匿名传输

4. rsync是一个功能非常强大的工具，其命令也有很多功能特色选项，我们下面就对它的选项一一进行分析说明。 Rsync的命令格式可以为以下六种：

　　rsync [OPTION]... SRC DEST

　　rsync [OPTION]... SRC [USER@]HOST:DEST

　　rsync [OPTION]... [USER@]HOST:SRC DEST

5. 从远程rsync服务器中拷贝文件到本地机。当SRC路径信息包含”::“分隔符时启动该模式。如：rsync -av  root@172.16.78.192::www  /databack

　 从本地机器拷贝文件到远程rsync服务器中。当DST路径信息包含”::“分隔符时启动该模式。如：rsync -av  /databack  root@172.16.78.192::www

-a, --archive 归档模式，表示以递归方式传输文件，并保持所有文件属性，等于-rlptgoD

-v, --verbose 详细模式输出

4、SVN分支策略（常用分支模式-摘自svn指南.doc）

参考资料：

Subversion1.4手册       http://www.subversion.org.cn/svnbook/1.4/svn.branchmerge.maint.html

Subversion1.6手册       http://i18n-zh.googlecode.com/svn/www/svnbook/zh/svn.tour.cycle.html#svn.tour.cycle.resolve

常用分支模式

版本控制在软件开发中广泛使用，这里是团队里程序员最常用的两种分支/合并模式的介绍，如果你不是使用Subversion软件开 发，可随意跳过本小节，如果你是第一次使用版本控制的软件开发者，请更加注意，以下模式被许多老兵当作最佳实践，这个过程并不只是针对 Subversion，在任何版本控制系统中都一样，但是在这里使用Subversion术语会感觉更方便一点。

发布分支

大多数软件存在这样一个生命周期：编码、测试、发布，然后重复。这样有两个问题，第一，开发者需要在质量保证小组测试假定稳定 版本时继续开发新特性，新工作在软件测试时不可以中断，第二，小组必须一直支持老的发布版本和软件；如果一个bug在最新的代码中发现，它一定也存在已发 布的版本中，客户希望立刻得到错误修正而不必等到新版本发布。

这是版本控制可以做的帮助，典型的过程如下：

开发者提交所有的新特性到主干。 每日的修改提交到/trunk：新特性，bug修正和其他。

这个主干被拷贝到“发布”分支。 当小组认为软件已经做好发布的准备(如，版本1.0)然后/trunk会被拷贝到/branches/1.0。

项目组继续并行工作，一个小组开始对分支进行严酷的测试，同时另一个小组在/trunk继续新的工作(如，准备2.0)，如果一个bug在任何一个位置被发现，错误修正需要来回运送。然而这个过程有时候也会结束，例如分支已经为发布前的最终测试“停滞”了。

分支已经作了标签并且发布，当测试结束，/branches/1.0作为引用快照已经拷贝到/tags/1.0.0，这个标签被打包发布给客户。

分支多次维护。当继续在/trunk上为版本2.0工作，bug修正继续从/trunk运送到/branches/1.0，如果积累了足够的bug修正，管理部门决定发布1.0.1版本：拷贝/branches/1.0到/tags/1.0.1，标签被打包发布。

整个过程随着软件的成熟不断重复：当2.0完成，一个新的2.0分支被创建，测试、打标签和最终发布，经过许多年，版本库结束了许多版本发布，进入了“维护”模式，许多标签代表了最终的发布版本。

特性分支

一个特性分支是本章中那个重要例子中的分支，你正在那个分支上工作，而Sally还在/trunk继续工作，这是一个临时分支，用来作复杂的修改而不会干扰/trunk的稳定性，不象发布分支(也许要永远支持)，特性分支出生，使用了一段时间，合并到主干，然后最终被删除掉，它们在有限的时间里有用。

还有，关于是否创建特性分支的项目政策也变化广泛，一些项目永远不使用特性分支：大家都可以提交到/trunk，好处是系统的简单—没有人需要知道分支和合并，坏处是主干会经常不稳定或者不可用，另外一些项目使用分支达到极限：没有修改曾经直接提交到主干，即使最细小的修改都要创建短暂的分支，然后小心的审核合并到主干，然后删除分支，这样系统保持主干一直稳定和可用，但是造成了巨大的负担。

许多项目采用折中的方式，坚持每次编译/trunk并进行回归测试，只有需要多次不稳定提交时才需要一个特性分支，这个规则可以用这样一个问题检验：如果开发者在好几天里独立工作，一次提交大量修改(这样/trunk就不会不稳定。)，是否会有太多的修改要来回顾？如果答案是“是”，这些修改应该在特性分支上进行，因为开发者增量的提交修改，你可以容易的回头检查。

最终，有一个问题就是怎样保持一个特性分支“同步”于工作中的主干，在前面提到过，在一个分支上工作数周或几个月是很有风险的，主干的修改也许会持续涌入，因为这一点，两条线的开发会区别巨大，合并分支回到主干会成为一个噩梦。

这种情况最好通过有规律的将主干合并到分支来避免，制定这样一个政策：每周将上周的修改合并到分支，注意这样做时需要小心，需要手工记录合并的过程，以避免重复的合并(在“手工跟踪合并”一节描述过)，你需要小心的撰写合并的日志信息，精确的描述合并包括的范围(在“合并分支到另一分支”一节中描述过)，这看起来像是胁迫，可是实际上是容易做到的。

在一些时候，你已经准备好了将“同步的”特性分支合并回到主干，为此，开始做一次将主干最新修改和分支的最终合并，这样以后，除了你的分支修改的部分，最新的分支和主干将会绝对一致，所以在这个特别的例子里，你会通过直接比较分支和主干来进行合并：

$ cd trunk-working-copy

$ svn update

At revision 1910.

$ svn merge http://svn.example.com/repos/calc/trunk@1910 \

            http://svn.example.com/repos/calc/branches/mybranch@1910

U real.c

U integer.c

A newdirectory

A newdirectory/newfile

…

通过比较HEAD修订版本的主干和HEAD修订版本的分支，你确定了只在分支上的增量信息，两条开发线都有了分枝的修改。

可以用另一种考虑这种模式，你每周按时同步分支到主干，类似于在工作拷贝执行svn update的命令，最终的合并操作类似于在工作拷贝运行svn commit，毕竟，工作拷贝不就是一个非常浅的分支吗？只是它一次只可以保存一个修改。

5、Subversion管理代码最佳实践

代码管理实践
代码仓库均采用svn来管理

5.1   代码目录的创建：
一般创建三个目录分别为
trunk(主干)，
tags（标签/标记)，
branches(分支)。
tags和branches下一般为根据需要从trunk目录拷贝过来的。

5.2   tags的创建要求：
代码在一种平台下通过编译（必须）
代码编译出来的版本通过一定的冒烟测试。
在项目要求的平台都可以编译通过。
一般有一个安装包给测试时，就需要在tags下建立对应代码的标签。
tags下的代码一般不可以修改。

5.3   两种代码管理模式介绍:
a、始终分支系统(OpenOffice社区采用管理方式)
典型特征:项目较大，代码较多，编译时间较长，参与人员比较多时。
每个用户对每项编码任务的创建或操作都是在私有分支中进行的。
编码完成后，原编码者、同级或经理将对所有私有分支的更改进行审查并将它由合并到 /trunk 中。
里程碑的创建
集成人员集成将开发人员提交的功能集成到主干上，编译通过后，提交的主干上，集成了一定的功能后，创建一个里程碑版本，一般建议按周创建里程碑版本。并在tags下创建相应的代码快照，并将安装包传至指定位置。
开发人员基于里程碑版本开发。
开发人员一般基于最新的里程碑版本创建分支，并在分支上工作，并在自己的分支上提交，在提交到svn之前需要编译通过。开发人员需要根据自己开发情况来同步到主干的里程碑代码。如果需要集成到主干上，需要同步到最近的里程碑。
测试人员.
测试人员对开发人员的代码进行测试，达到一定的测试标准后，测试通过，然后交由集成人员来集成。

b、按需分支系统（Subversion社区采用管理方式）
适用方式代码较少，或者参与开发的人员较少
开发人员可以直接在主干上提交。开发负责人来编译版本给测试。
开发者把所有的新特性提交到主干。 每日的修改提交到/trunk：新特性，bug修正和其他。新近的开发人员不能提交代码，交由有经验的开发人员验证后来提交到主干上。
当开发小组认为软件已经做好基本发布的准备(如，版本1.0)然后/trunk会被拷贝到/branches/1.0。这个主干被拷贝到“发布”分支。然后在发布分支上继续修改bug.
如果bug修正经测试达到一定的要求认为可以完成时，可以拷贝到/tags/1.0.0，这个标签被建立并发布给相关人员。

5.4   向svn库提交提交代码要求
针对每次提交到主干上的代码均需要编译通过
代码每次提交到svn上均需要添加注释。
每个人都用自己账号来提交代码。

6、参考资料

l         分支模式在SVN环境下的应用

http://www.webwoo.net/SVN/svnsy/2009/1211/51007.html

l         持续集成之“分支策略”

http://wwling2001.blogbus.com/logs/164479726.html

l         SVN常用分支模式

http://i18n-zh.googlecode.com/svn/www/svnbook-1.4/svn.branchmerge.commonuses.html

l         配置管理一问一答

http://qa.uml.net.cn/Question/List.aspx?t=1&tid=13&tn=%E9%85%8D%E7%BD%AE%E7%AE%A1%E7%90%86&area=0

l         百度-主干开发，分支提测

http://www.cnblogs.com/topiemie/

l         subversion管理代码最佳实践

http://www.zxbc.cn/html/20081212/68890.html

l         Subversion中文站

http://www.subversion.org.cn/?action-category-catid-1

l         Subversion FAQ(常见问题解答)

http://subversion.apache.org/faq.zh.html

2012工作计划

工作总结需含概以下内容：

1、   简述您上一个年度所具体负责的工作、工作业绩，以及您对自己的工作业绩是否满意；

2、   简述您的下一步工作及学习计划，以及您今后的工作目标定位；

3、   期望公司及部门改善的地方；

1. 从事版本管理工作之后，2011主要完成如下工作：

1）.编写软件配置管理文档：如软件配置管理计划，及软件配置状态报告。

2）.根据深圳SCM主管的配置管理整理方案，完成对上海各事业部的配置库目录结构的整理及权限文件的整理，提高代码资源的管控。

3）.在上海公司使用统一编译服务器，统一项目编译环境，保证代码及时提交入库。

4）. 推广持续集成，自动编译，提高网关研发同事出版本的效率,及代码编译不通过的提醒，自测可以直接从CI工具hudson中取得，同时保证研发自测版本与测试部版本的一致性；

5）. 增加SVN密码修改模块，通过自己查找资料，经过环境搭建测试，完成SVN密码修改模块，同时统一上海代码服务器的账号文件，清除废弃及重复的账号，避免相同的服务器使用多个账号，避免了混乱麻烦的状况。。

6）. SVN服务器备份，使用本地备份及异地备份，全量备份与增量备份相结合的方式，进行代码库数据的备份，避免一旦服务器出现异常导致无法使用带来的巨大损失。

7）. 深圳同事提交代码出现卡死的情况，针对深圳同事的具体情况，使用账户模拟场景，再现问题，及研究SVN触发的脚本，找出问题根源，并测试通过，改善了同事的工作过程。

8）. 深圳配置管理主管指导交流，提高了我自己对配置管理的认识，同时按照深圳高工给出的配置管理方案对上海代码库进行整理，目前已经完成EOC，无线，网关的代码库整理工作，然后我们会严格按照配置管理策略来指导及执行项目的配置管理工作。

2. 2012的工作及学习计划如下：

1）.策划一组SVN系列培训，提供研发同事使用SVN的熟练程度。

    大致会包括如下的培训内容：

SVN客户端使用；

SVN服务器使用；

SVN常见问题解决方法；

2）.精通shell，使版本管理工作更高效。

3）.努力参与项目，使软件配置管理更加深入项目，做好软件配置管理的本职工作，改善研发过程。

按照软件配置管理计划来参与项目，完善软件配置状态报告，及项目基线管理及版本管理；

4）.精通SVN，提高应对版本库出现的各种问题的解决能力。

5）.深入了解软件配置管理思想，在工作中要尽可能的去体会以及应用在工作中。需要多搜集资料，学习别人的经验，同时结合本公司现状，加以应用。力求把上海的配置管理工作做好，做到位。

6）．尝试实现SVN二次开发，提高研发过程。

7）.开展软件配置管理系统培训，普及软件配置管理知识，培训内容包括：

           SCM基本概念培训；

           SCM规范培训；

           SCM策略培训；

严格按照软件产品发布流程发布软件版本是建立和完善软件产品版本控制，保证软件产品质量的关键过程之一。参与软件产品发布的人员主要是测试负责人和BM（Build Master）。

公司软件产品发布的规程如下：

1、 发布准备。
发布之前，所有程序freezed由测试人员进行确认测试；
检查qcs系统内登记的所有bug都已经被fixed，或者遗留的bug不影响系统的使用，如果有严重bug未解决（级别为must fixed）不能发布；
程序打包前做冒烟测试。

2、 测试负责人编写release产品质量报告进行质量分析和总结。

3、 源码、文档入库。
源码包括数据库创建脚本（含静态数据）、编译构建脚本和所有源代码；
文档包括需求、设计、测试文档，安装手册、使用手册、二次开发手册、产品介绍（ppt）、使用demo等。

4、BM进行程序打包；标记源码、文档版本tag。

5、 BM填写发布基线通知并通知相关人员；BM经理对发布基线进行审计。

6、在qcs系统上新建产品发布计划，填写配置项，执行发布计划（发布产品）。

7、上传程序包、使用文档至download站点。

8、 编写发布说明readme.txt（或者release note）。
Readme的内容应该包括产品版本说明、产品概要介绍、本次发布包含的文件包、文档说明、本次发布包含或者新增的功能特性说明、遗留问题及影响说明、版权声明以及其他需要说明的事项。

9、 正式发布通知。
通知开发、测试、市场、销售各相关部门并附上产品发布说明和产品介绍。

10、后续工作。
产品发布后，在使用过程中可能还会发现一些bug。在不影响正常使用的情况下，这些bug将在下一版本发布时解决；如果bug严重影响使用，必须打patch或者按照流程重新发布。

11、 临时发布。
软件产品未正式发布前，可能需要一个临时版本供开发人员或者用户应急使用，这时候需要临时发布一个版本。这个版本只包括基本的程序包和必要的使用说明。临时发布需要通知相关开发、测试人员；BM需要为源码、文档打tag标记。

12、 软件产品发布后，即建立了一条发布基线。
所有用户安装及二次开发必须在此基线上进行，开发人员不能直接从cvs或vss上check 代码编译交付用户使用或者进行二次开发。

另一种说法：

公司软件产品发布的规程如下：
1.FAE首先向版本管理员提交需求;
2.版本管理员将需求提交给项目经理,由经理确认需求以及发布基线;
3.发布准备:发布之前，先将当前主干中的所有程序freezed,并从主干中拉出一条发布分支branch,由开发人员对其进行功能测试:检查所有bug是否都已经被fixed，或者遗留的bug不影响软件的使用，如果有严重bug未解决暂时不能发布。
4.如果测试通过,则由相关开发人员进行程序打包；标记源码、文档版本tag。
5.开发人员将标记的源码和文档地址交予版本管理员,由版本管理员编写发布说明release list.release list内容应包括本次发布包含的文件包、文档说明;各类文件的存放路径,提供者及tag信息;本次发布包含或者新增的功能特性说明；遗留问题及影响说 明；版权声明以及其他需要说明的事项。
6.管理员在jira上建立测试任务并邮件通知相关测试人员。
7.FAE测试,测试完成后，FAE向版本管理员反馈测试结果（确认所提需求是否全部实现，不然则列出哪些功能还存在不足或BUG）:如果测试没有通过， 将由版本管理员向开发组请求重新release内部版本，再交FAE重新测试;如果测试通过，则由版本管理员为当前的版本进行标记和命名,同时提交到发布 库中.
8.正式发布通知。邮件通知各相关部门并附上产品发布说明和产品介绍。
9.由FAE将发布后的版本打包release给客户;
10.后续工作。产品发布后，在使用过程中可能还会发现一些bug。在不影响正常使用的情况下，这些bug将在下一版本发布时解决；如果bug严重影响使用，必须打patch或者按照流程重新发布。
11. 临时发布。软件产品未正式发布前，可能需要一个临时版本供开发人员或者用户应急使用，这时候需要临时发布一个版本。这个版本只包括基本的程序包和必要的使用说明。临时发布需要通知相关开发、测试人员；管理员需要为源码、文档打tag标记。
12. 软件产品发布后，即建立了一条发布基线。所有用户安装及二次开发必须在此基线上进行，开发人员不能直接从svn上check 代码编译交付用户使用或者进行二次开发。

问题一：

@ERROR: chroot failed

rsync error: error starting client-server protocol (code 5) at main.c(1522) [receiver=3.0.3]

原因：

服务器端的目录不存在或无权限。创建目录并修正权限可解决问题。

问题二：

@ERROR: auth failed on module tee

rsync error: error starting client-server protocol (code 5) at main.c(1522) [receiver=3.0.3]

原因：

服务器端该模块（tee）需要验证用户名密码，但客户端没有提供正确的用户名密码，认证失败。提供正确的用户名密码解决此问题。

问题三：

@ERROR: Unknown module ‘tee_nonexists’

rsync error: error starting client-server protocol (code 5) at main.c(1522) [receiver=3.0.3]

原因：

服务器不存在指定模块。提供正确的模块名或在服务器端修改成你要的模块以解决问题。

问题四：

password file must not be other-accessible

continuing without password file

Password:

原因：

这是因为rsyncd.pwd rsyncd.secrets的权限不对，应该设置为600。如：chmod 600 rsyncd.pwd

问题五：

rsync: failed to connect to 218.107.243.2: No route to host (113)

rsync error: error in socket IO (code 10) at clientserver.c(104) [receiver=2.6.9]

原因：

对方没开机、防火墙阻挡、通过的网络上有防火墙阻挡，都有可能。关闭防火墙，其实就是把tcp udp的873端口打开。

问题六：

rsync error: error starting client-server protocol (code 5) at main.c(1524) [Receiver=3.0.7]

原因：

/etc/rsyncd.conf配置文件内容有错误。请正确核对配置文件。

问题七：

rsync: chown "" failed: Invalid argument (22)

原因：

权限无法复制。去掉同步权限的参数即可。(这种情况多见于Linux向Windows的时候)

引言

Thomas Carlyle说：“人类是使用工具的动物。没有工具，人什么都不是；有了工具，人无所不能。”金融家们创造了复杂的金融工具，并利用这些工具制造了财富 神话，制造了著名的跨国公司，也制造了世界范围的危机。软件精英们为了让自己的工作效率更高，有更多时间去做想做的事，也创造了各式各样的工具。持续集成 已经不是一个新概念，在这个概念发展的十多年间，出现了支持这一概念的众多工具。这些工具的组合使用，为软件开发提供了强大的支持。

持续集成工具的分类和功能

一般来说，持续集成工具可以分成两大类：自动化构建工具和构建计划安排工具。

自动化构建工具有这样一些基本功能：代码编译、组件打包、程序执行和文件操作。编译源代码是构建的主要工作之一，为了提高效率，编译应该根据相应的 源代码是否发生改变而有条件地执行。组件打包是将编译的结果和其他需要包含的文件组织在一起，形成可以部署的组件。构建工具应该知道何时需要重新打包。程 序执行是指构建工具能够在它支持的平台上，调用所有提供命令行接口的程序。构建工具应该支持创建、拷贝、删除文件和目录等操作。

某些自动化构建工具还有一些扩展功能：执行开发者测试、版本控制工具集成、文档集成、部署功能、代码品质分析、支持扩展、多平台构建、加速构建。虽 然构建工具可以通过命令行执行的方式来集成构建工具和测试工具，但如果它提供更直接的集成方式，开发者就更省力。同样，如果构建工具能够直接与版本控制工 具集成，开发者也会觉得更方便。文档集成是指构建工具能够自动从源代码中抽取并生成API文档。构建工具还可以将打包好的组件自动部署到目标测试环境中 去。构建工具一般通过一些第三方插件，支持对代码品质进行分析。而提供插件接口，是构建工具实现可扩展性的通用方式。如果您开发的软件需要在多个平台上构 建并测试，那么构建工具对多平台的支持就会带来极大的方便。对于较大的代码集，一次构建可能需要好几个小时，这为持续集成带来了一些挑战。有的构建工具支 持加速构建，即在多个构建服务器的多个处理器上进行分布式构建。

常见的自动化构建工具包括Ant、NAnt、MSBuild、make、Maven、Rake等。

构建计划安排工具有这样一些基本功能：构建执行、版本控制集成、构建工具集成、提供反馈、为构建打上标签。构建计划安排工具的核心功能就是在特定时 间执行自动化的构建，这可以通过轮询版本控制库、计划驱动或事件通知等方式来实现。大部分构建计划安排工具都支持大多数流行的版本控制系统，也支持大多数 流行的构建工具。构建计划安排工具至少支持通过电子邮件提供反馈信息，有一些工具可以通过即时消息、手机短信或其他设备来提供反馈。大多数构建计划安排工 具会提供某种类型的升序计数，作为构建版本的标签。

某些构建计划安排工具还有一些扩展功能：支持项目间依赖关系、提供用户界面、制品发布、安全。如果项目间存在依赖关系，您可能希望在被依赖的项目重 新构建时，重新构建依赖于它的项目。设计良好的用户界面会在工作时为您节约时间。制品发布是指除了得到可部署的组件之外，一些成熟的某些构建计划安排工具 可以将文档、测试结果、品质分析结构和其他测量指标数据格式化，便于查看。有一些工具提供了身份认证和授权等安全方面的功能，允许您指定谁能查看结果和修 改配置。

常见的构建计划安排工具包括AnthillPro、Continuum、CruiseControl、CruiseControl.NET、Draco.NET、Luntbuild、Hudson等。

下面介绍两个颇具代表性的工具：Ant和Hudson。

Ant

Ant是Java构建工具的事实标准，一般建议，不论项目团队成员使用哪种集成开发环境，项目都要有一个可以脱离IDE执行的Ant脚本。Ant采用插件式的设计结构，通过不同的插件来实现各种任务，其任务分类如表1所示。

Archive Tasks
 打包解包任务，支持的格式包括：BZip2、Cab、Ear、GZip、Jar、Rpm、Tar、War、Zip。
 
Audit/Coverage Tasks
 JDepend任务，调用JDepend实现代码静态分析，针对每个Java包生成设计品质指标数据。
 
Compile Tasks
 编译任务，实现对Java、JSP、NetRexx等源文件的编译。
 
Deployment Tasks
 部署任务，实现在JavaEE服务器上热部署。
 
Documentation Tasks
 文档生成任务，生成javadoc文档、Apache Stylebook文档。
 
EJB Tasks
 EJB任务，提供对1.x和2.x的EJB的支持，并支持不同供应商的应用服务器。
 
Execution Tasks
 执行任务，包括对子项目调用Ant、调用同一脚本中的另一个target、执行系统提供的命令行程序、执行Java程序、暂停和并行同步执行等功能。
 
File Tasks
 文件任务，实现对文件和目录的操作。
 
Java2 Extensions Tasks
 Java2 扩展信息任务，对jar包中的版本、供应商等扩展信息进行检查和操作。
 
Logging Tasks
 日志任务，将构建过程事件记录到文件中。
 
Mail Tasks
 邮件任务，发送SMTP邮件。
 
Miscellaneous Tasks
 其他任务，各种或许会用到的小任务，例如播放wav文件。
 
.NET Tasks
 .NET任务，支持执行.NET程序、执行NUnit测试、调用NAnt、调用MSBuild、调用WiX工具。
 
Pre-process Tasks
 预处理任务，实现编译之前的一些预处理。例如调用ANTLR、JavaCC、Native2Ascii等程序。
 
Property Tasks
 属性任务，对脚本中的属性变量进行判断和操作。
 
Remote Tasks
 远程任务，支持FTP、Rexec、Scp、SSH和Telnet。
 
SCM Tasks
 SCM任务，支持各种配置管理（版本控制）软件，包括CVS、ClearCase、Continuus、Visual SourceSafe、Perforce、PVCS、SourceOffSite和StarTeam。
 
Testing Tasks
 测试任务，支持执行JUnit测试。
 
表1. Ant任务分类

以上介绍的只是Ant发行版所带的一些任务。由于Ant采用的是插件结构，所以开发者可以开发自己需要的Ant任务，支持各种工具，如FindBugs、TestNG等其他代码检查工具和测试工具。早期的Ant没有很好的依赖关系支持，后来则通过Ivy弥补了这一缺点。

关键是Ant为我们提供了一个跨平台的Java构建工具，为持续集成提供了根本的支持。对于Java开发者来说，如果不想采用Ant，也可以考虑采用Maven。

Hudson

Hudson是一个开放源代码的CI服务器，受到世界各地各种规模和类型的开发团队的欢迎。关键是因为它非常易于安装和使用，提供了灵活的配置方式和复杂的功能，同时支持Java项目和非Java项目，由强大的Hudson社区提供技术支持。

简而言之，Hudson不仅仅是一个CI服务器，它的可扩展架构使它不仅是一个构建管理系统，也成为一个通用的开发生命周期管理系统，让开发者能够完成提升基线、打标签、执行工作流、根据依赖关系追踪变更、监视并图示测试结果、查看代码覆盖率和违反编码标准的情况等任务。

Hudson是最活跃，成长最快的开源社区之一，目前每周下载达4000次，有超过2万个在工作的安装实例。它的开发者超过160人，贡献的工作量超过137人年，目前已发布了超过300个发行版本。Hudson实际上是现在世界上最受欢迎的开源CI服务器。

图1是Apache软件基金会运行Hudson的屏幕截图，您可以在http://wiki.hudson-ci.org/display/HUDSON/Meet+Hudson 看到更多Hudson的使用案例。

图1. Apache运行的Hudson

Huddon的主要优点包括：

易于安装。只要执行“java –jar hudson.war”，或者将hudson.war部署到应用服务器上就可以了，不需要其他的安装工作，也不需要建立数据库。
易于配置。所有东西都通过Web GUI界面来配置，不需要手工修改XML文件。
支持分布式构建。Hudson支持将构建和测试负载分布到多台机器上，图2是Apache采用Hudson的分布式构建功能。
支持环境配置矩阵。Hudson支持在不同的环境配置下执行相同的任务，例如不同的JDK版本、不同的操作系统、不同的数据库。执行的结果可以汇总在一起。
支持JUnit/TestNG测试报告。测试的结果可以分标签列出、汇总，并与历史信息一同显示。历史趋势可以显示在图中。
追踪依赖关系。Hudson追踪记录哪次构建生成了哪些jar，某次构建使用了哪些版本的jar，即使这些jar包来自于外部也可以。

图2. Hudson支持的分布式构建

Hudson通过大量的插件来实现其丰富的功能，这些插件大致可以分为以下几类：

SCM。Hudson缺省支持CVS和Subversion，通过安装插件支持Accurev、Bitkeeper、ClearCase、Git、Mercurial、Perforce、StarTeam、Synergy等
构建触发器。可以通过IRC、Ivy、Jabber、Join、Locks and Latches、Navigator来触发执行构建。
构 建工具。缺省支持Ant、Maven、shell s和Windows 批处理命令，通过安装插件支持batch tasks、Gant、Gradle、Grails、Groovy、Jython、Kundo、MSBuild、Phing、Powershell、 Python、Rake、Ruby、SCons、SCTMExecutor,Selenium等。
构建包装。对构建的方式进行一些控制，如并发 同步、启停虚拟机等。包括Hudson Centralized Job Action、Hudson Distributed Workspace Clean、Locks and Latches、M2 Extra Steps、M2 Release、Release、VMware、Xvnc、Zen Timestamp等。
构建通知。缺省支持电子邮件通知，通过插件支持 Campfire、Google Calendar、HudsonTracker (RSS feeds)、IRC、Jabber、Nabaztag、SameTime、Status Monitor、The new Emailer、TuxDroid、Twitter等。
Slave启动和控制。缺省支持JNLP和命令行，通过插件支持SSH。
构建 报告。缺省支持JUnit、javadoc和FindBugs，通过插件支持CCCC、Checkstyle、Clover、DRY、Emma、 Gallio、Gnat、Grinder、Japaex、JavaNCS、JavaTest Report、MSTest、N Cover、NUint、Plot、PMD、PureCoverage、Ruby metrics、Selenium AES、Selenium hq、Serenitec、SLOCCount、Task Scanner、Testability Explorer、Violations、Warnings、WebTest Presenter等。图3是Sonar生成的项目报告的样例。
集群管理/分布式构建。支持DistFork、Hadoop、PXE、Selenium、Swarm等。
制品上传。支持FTP-Publisher、java.net uploader、SCP,SFEE、SVN等。
身份认证和用户管理。支持操作审计追踪、LDAP、MySQL认证等。

图3. Sonar Dashboard

结束语

工欲善其事，必先利其器。人是工具的主宰。A fool with a tool is still a fool（傻子拿着工具还是傻子）。人们总是在学习工具、使用工具、创造更好的工具，以期提高工作的效率和品质。人要有智慧，工具要先进。

【windows OS系统下的： Hudson环境搭建过程记录】

1. 安装jakarta-tomcat-5.0.30.exe, 使用的jdk（C:\Program Files\Java\jdk1.6.0_14）。

设置HUDSON_HOME环境变量，按住windows键+Pause键快速出现环境变量设置界面。

HUDSON_HOME=C:\hudson_ci\hudson

TOMCAT_HOME=C:\hudson_ci\Tomcat 5.0

       JAVA_HOME=C:\Program Files\Java\jdk1.6.0_14

       CALSSPATH=C:\ProgramFiles\Java\jdk1.6.0_14\lib\dt.jar;C:\ProgramFiles\Java\jdk1.6.0_14\lib\tools.jar

2. hudson-2.0.0.war copy到C:\hudson_ci\Tomcat 5.0\webapps目录。

3. 访问http://localhost:8080/hudson-2.0.0/出现hudson web页面。

=============================================================

【linux (fedora)系统下hudson搭建过程】

1. fedora机器的一些信息

       IP：172.28.6.36（7楼时）

       PC账户：root/123456

2. 安装JDK jdk-6u21-linux-i586-rpm.bin (JDK6)

(下载页面

http://zh.sourceforge.jp/projects/sfnet_crawlzilla/downloads/other/jdk-6u21-linux-i586-rpm.bin/)

执行：./ jdk-6u21-linux-i586-rpm.bin

[root@localhost ~]# vim /etc/profile

在最下面加入如下内容

JAVA_HOME=/usr/java/jdk1.6.0_21 #你的jdk所在目录

PATH=$PATH:$JAVA_HOME/bin

CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar

export JAVA_HOME

export PATH

export CLASSPATH

1) 马上生效：

[root@localhost ~]# source /etc/profile

3）查看是否已生效

[root@localhost kikitest]# java -version

java version "1.6.0_21"

Java(TM) SE Runtime Environment (build 1.6.0_21-b06)

Java HotSpot(TM) Server VM (build 17.0-b16, mixed mode)

3. 安装Tomcat6

tar xzvf  apache-tomcat-6.0.32.tar.gz

4.

PS:

1.） 之前试过2次jdk和tomcat6都安装好的情况，每次浏览hudson就出现内存泄露的情况，是因为hudson-2.0.1.war和hudson-2.0.0.war虽然在windows环境访问OK，但是在fedora中不兼容，于是从hudson官网下了个hudson.war，部署到webapps最终搞定。

2.）

yum list | grep tomcat    //列出tomcat可安装包

yum -y install tomcat5   //安装tomcat5

yum remove tomcat5     //卸载tomcat5

yum remove java          //卸载所有JAVA

rpm –qa | grep jdk         //查找jdk

查看方法:rpm –qa |grep –I java

卸载方法:rpm –e –nodeps java*包名

将jdk-6u21-linux-i586-rpm.bin给予可执行权限

修改权限：chmod u+x jdk-6u21-linux-i586-rpm.bin

SVN里的钩子脚本（T&W）

【post-commit】S204提交之后邮件通知

#!/bin/sh

REPOS="$1"

REV="$2"

DOMAIN=twsh.com

PROJECTNAME=`basename $REPOS`

/urr/local/ActivePerl/site/bin/svnnotify

--repos-path "$1"

--revision "$2"

--to $PROJECTNAME@$DOMAIN

--user-domain $DOMAIN

--smtp 10.58.100.8

--smtp-user svn@twsh.com –

-smtp-pass 15021151553

--subject-prefix [SVN:$PROJECTNAME] -g en_US

--handler "HTML::ColorDiff"

--with-diff

--diff-encoding GBK

【post-commit】DSL库提交之后的邮件通知（DSL是一个大库，里面包含很多小项目库）

.

#!/bin/sh

REPOS="$1"

REV="$2"

DOMAIN=twsh.com

PROJECTNAME=`basename $REPOS`

PATHFILTER='4.02L.03_CT_BCM963293+TK3715_E8C_EPON\|Gewv2.3L19A-B2-V03'

SVNLOOK=/usr/bin/svnlook

if ( $SVNLOOK dirs-changed -r $REV "$REPOS" | grep "$PATHFILTER" > /dev/null ); then

    /urr/local/ActivePerl/site/bin/svnnotify \

        --repos-path "$REPOS" \

        --revision "$REV" \

        --to ponsw@twsh.com \

        --user-domain $DOMAIN \

        --smtp 10.58.100.8 \

        --smtp-user svn@twsh.com \

        --smtp-pass 15021151553 \

        --subject-prefix [SVN:$PROJECTNAME] \

        -g en_US \

        --handler "HTML::ColorDiff" \

        --with-diff \

        --diff-encoding GBK

fi

【pre-commit】提交之前LOG限制

#!/bin/sh

REPOS="$1"

TXN="$2"

SVNLOOK=/usr/bin/svnlook

if ( $SVNLOOK log -t "$TXN" "$REPOS" | grep "[a-zA-Z0-9]" > /dev/null ); then

        exit 0;

fi

echo "Empty log message not allowed. Commit aborted!" >&2

exit 1;

【pre-revprop-chang】实例验证过，可修改:author and log message.

#!/bin/sh

REPOS="$1"

REV="$2"

USER="$3"

PROPNAME="$4"

ACTION="$5"

http://bbs.scmlife.com/thread-16353-1-1.html k/ o3 Y6 g) j" ^0 z2 E) o( v9 L5 O
我在做配置管理以前做过两年的测试，期间做过两家公司的iso 9000的内审员，然后老板觉得我比较有耐心，所以赶鸭子上架，和前任学习拉一周，我就是配置管理拉，然后不知不觉，已经6年拉，总结一下，看看会需要些什么呢？
1、软件公司的开发流程，对软件工程一定要熟悉，尤其是开发模型，你不能保证公司的所有项目使用一个模型。比如：瀑布、迭代或者极限编程。只有熟悉这些开发模型，你才能参与到公司的流程制定中去。
2、 熟悉一些标准，比如：iso 9000和cmmi。一个公司想要发展大，想要稳定，就一定会有一套稳定的流程。而熟悉标准，会更有利于你理解和说服你的同事。记得以前一个同事说过这样 一句话，一个公司想要长大，那一定必须是一头小象而不能是一只大蚂蚁。而一个做有流程，愿意将公司的事情流程化的公司才能保证不因人成事，才能长大。. @5 "9 E: Q( L0 j1 ~
3、沟通能力。配置管理员的工作就是沟通协助需求、开发及测试人员工作。而一个新的项目的建立意味这大家都是新人，来自不同的行业不同的公司，公司文化不 同，做事的方法也不同，你只有有好的沟通能力，才能说服项目经理支持你的工作，才只能说服开发测试人员按你要求的流程工作。
4、编程能力。想做好配置管理，你就不得不编写一些配置脚本，以方便开发测试人员，同时减少自己的工作量。
5、数据库知识。一般来说配置管理员，同时要管理BUG跟踪或需求管理的系统，那免不了老板会让你提供一些统计数据，所以数据库知识也是必不可少的。
6、系统知识。多说公司的配置管理员还要负责开发测试环境的维护，那么有系统知识，无疑可以减少你求助的机会。
现在说说我做过什么？& g! @2 `9 [: f+ ]5 g! z4 "/ f. q
一、上海项目的时候，只是负责系统的配置管理，包括代码编译，上线，这个系统比较大，但是还好，我是从别人手上接手的，所以还在顺序。
二、集团项目的的时候，我同时维护9个省的测试上线环境。
由于用户一直是用unix系统，所以顺便学会拉shell ，学会来在ibm，hp，sun的小型机上安装配置软件。
尤其是bes521的安装，简直是无言啊？宝 蓝从总部派人过来，现场安装，配置、测试，美国总部修改bug，然后打补丁，终于，我写了一本安装手册，两年后公司同事还在用。安装ibm的 websphere的时候，我发现需要打操作系统补丁，于是比较傻瓜的我，安装拉最新版的补丁，要命的是这个websphere比较变态，尽然只能用它指 定版本，所以到现在我都恨websphere啊。
要说最大的收获，就是在压力下面，我做事情很负责，我的努力让公司项目经理面对甲方也很硬气。! b  ^/ I7 E/ s" V
三、做公司的openboss系统。这个系统对我的锻炼很大，工作如下：/ d2 ?% d/ f1 K& d0 Y) I
1、写cvs脚本，保证代码能在提交的时候,同时建立开发和构建分支，同时不能是分支之上建立分支。
2、和一个没有任何配置管理经验的开发团队扯皮，扯开发流程，扯目录结构，扯Makefile模板，扯代码命名规范，然后想办法让他们执行。9 U1 J- G8 r0 ^2 D% i+ N6 Z
这个系统很大，到今天，已经有11个移动，3个网通，3个电信在使用。分出来的系统现在也有15个拉，仅仅营业和账务两个系统，unix后台就有500多个动态库，当时扯皮，现在受益。
3、和总工办 一起搞unix主机下的编译选项，由于用户的环境复杂，所以要求做到，代码写出来后，可以跨cpu，跨操作系统、跨中间件、跨数据库。所以这个过程让我对 unix下的编译器熟悉起来，不然无法做到。让我自豪的是到现在，开发人员只要修改Makefile模板很少的地方，就可以跨平台编译拉。
4、编写自动编译脚本。通过我们开发的自动编译系统，开发人员只要在浏览器中提交编译单就可以自动编译拉。而如果开始的时候，如果没有将目录规划好，我想自动编译就是无源之水。6 H& H1 ?% b; n5 N
这个系统我们web部分用jsp，unix用tcl/tk脚本。现在已经集成到QCS的源码管理中，还在改进，还在使用。7 r) H# K. ~- i6 r

四、公司的QCS系统（质量控制系统）。
这是一个配置管理系统，通过rsh将CVS和QCS结合在一起，用jsp和oracle的存储过程开发，其中包括：需求管理、功能点管理、任务管理、源码管理、bug管理、工程故障管理、接口管理、数据库变更管理、版本管理、发布管理、回退管理等模块的系统。2 z( T! {' a7 c* J: A0 v" M

五、参加公司的EPG小组，并且以配置管理员的身份参与评审。+ E* F) S  j( B' |# F# u  ^
公司两年前已经通过CMMI 5的认证。我加入公司的公司只是通过拉CMM 2级。后来由于甲方的要求，公司开始CMMI的认证。这中间有大量的文档要写。尤其是配置管理员，在几乎所有的过程中，都要参与评审，所以准备工作做拉好 久。到 CMMI 5级的时候，就要提供大量的统计数据来说明持续改进的结果，所以对QCS就需要不少地方做改动，来收集数据。还好公司一直注意这块，我们的各种脚本，模 板，都是尽量的优化以满足开发测试人员的需要。所以后来的评审中基本没有费什么事就过拉。* G6 J3 w5 "# z
( [" N- P( V% F4 "$ d, `
在这个项目中，让我对配置管理中的很多概念理解很深。尤其是在评审的时候，将自己平时做的工作用CMMI的语言讲解，感觉的确是锻炼人。
- a% k3 H% s/ Q5 S# ^, |+ T
这中间的很多事情，我的感谢我的师傅，虽然他比我年龄还小，而且也没有带我很久，但是很多问题都是和他讨论中加深理解的，不管是从技术上，还是为人都让我学之不尽啊。
1 h( "  C) "8 r  t- @7 C
要做好配置管理，一定要耐心、细心、恒心。
冰冻三尺非一日之寒。, H3 N' z: f+ I  y' V) K
* j; V, r: J* w, x; P9 p! ]
希望以上内容能给新入行的同行一点帮助。
原文：

原文：http://bbs.scmlife.com/thread-16603-1-1.html

一个项目想要成功，那配置管理的努力是必不可少的。如何做一个好的配置管理，同时减轻自己的负担，那就是一个值得认真思考的问题拉。+ Z, Z7 d1 W/ J/ e) Q0 A* O1 J# i+ X
一个产品想要实现持续集成及日创建，那么非得有一套好的自动编译系统支撑才可以，否则对于一个庞大的系统而言，一个配置管理就算累死也无法满足需求的。
下面以我的经验说说任何构建一个自动编译系统。
$ E( i$ {4 U: N
为了更好的自动编译，我想应该建立一个这样的系统，那就是：
1、开发人员或定时触发。
2、自动更新编译环境。- P$ e; s  `% ^" c* U2 A0 L
3、自动编译。
( b: C$ m* F  t: W9 w  l4、自动分析编译结果。. U5 A! [6 X4 h6 Z2 ]+ |4 V9 v
5、自动通知开发、测试及配置管理员。$ C+ ~9 h& D! y4 m" c% d

下面我假设情况如下：
1、操作系统：平台包括：HP-UX、SunOS、AIX、Linux 、Windows （均包括多个版本）、。  M! c$ t9 ": k
2、数据库包括：oracle 8i、9i、10G
3、编译器包括：aCC、CC、xlC、gcc、bcb(windows 上的集成开发环境) 、java（包括多个版本）/ R" N3 J* F$ "% L- R, D' b
4、项目规模超过千万行代码、模块众多、调用复杂。# H! A# y: "8 J% f7 C, G! j" `( E
那么在这样一个情况下，如果我们考虑用一般的商用工具做，显然成本是很高的。0 y; l( I* Y: x
对于这样一个庞大，复杂的系统，我想在项目启动后，首先要做的是：
1、定义编码规范。0 L# S* D9 |' y2 @3 @1 G  h
2、定义C++及java的编译选项（由于C++语言中编译器及平台版本不同，32、64位要求及数据库的版本等不同要求，所以编译选项显然要提取出来单独处理）。
3、定义Makefile 规范。
4、定义模块目录结构。
5、定义接口提供方式。
4 C( J  w$ v1 n* _  {, {+ m在定义以上内容的时 候，一定要遵循一个原则，符合命名规范、尽量可配置、易懂、易于理解。最后组合出的编译命令的字符串不要太长（unix操作系统下，不同版本的shell 对一个命令的长度有不同要求、同时由于Makefile中如果有很多shell 脚本的话，编译性能也会受影响）。3 U& P* h8 Q6 x& A8 E+ P
在我用过的系统中，make 工具，unix 平台我们使用的是 GNU make 版本3.80，java 用的是 ant，windows 平台C++用的是bcb 自带的make，不过在编译前先要将bcb的工程文件bpr文件转换为Makefile文件，使用的工具是bpr2make（之所以不用bcb直接编译， 主要是为拉自动编译，自动分发编译结果）。
2 [3 `" W; x% d- O
为了更好的跟踪代码及需求、bug变更情况，自动编译系统，应该从开发人员提交代码开始，到发布结束。( W- J% J4 O4 O/ E, a" m% s
流程如下：( V+ t: ~4 G+ }3 V* e' H; G8 ": k
1、开发人员提交代码。
2、编译脚本触发，从版本库更新代码到编译服务器。
3、设置编译需要的环境变量。
4、构造编译需要的Makefile。6 z% i( G5 ~. U2 l( q# I3 ^+ z9 ~
5、执行编译。
6、分析编译结果、记录编译结果。* N2 |9 P5 d% i: N. L
7、发邮件通知开发、配置管理、测试人员等相关人。# k5 |$ u9 ]2 `1 L2 ]0 I
8、更新到测试环境测试。  t, {9 D4 y3 ?7 v( Y5 q8 H- @
9、配置管理员发布。
2 ]2 b# _: ]5 q5 S# G! S* F
下面我以cvs或svn为源码版本库做作说明，需要写一些适当的脚本，并且需要数据库的配合才能工作的比较顺利。
1、建议用户表
( z  q  O: |- F0 R6 r2、在数据库中建立产品表。
3、在数据库中建立模块表（需要记录模块优先级、模块路径、Makefile 文件的名称等功能）。/ w* n9 y' D3 y3 R( L3 u9 x
4、建立需求表、任务单表、bug表、编译记录表。, s' t5 N4 m5 L& t) N- Q* X* [
5、编写代码提交脚本。实现提交代码的同时，在编译记录表中增加记录，并关联需求单、任务单、BUG单功能。3 O+ N0 n3 e2 p' f
6、编写自动编译脚本。实现定时查询数据库，根据编译单，进行编译的功能。需要实现，获取编译单后，自动生成编译环境所需的环境变量，构造编译用 Makefile，更新待编译代码，编译完成后分析编译结果，给被编译代码打tag，获取编译结果的特征串，然后记录到数据库中，并发邮件通知开发人员、 测试人员及配置管理人员。

如果以上脚本实现，那么，不管你是要日创建还是随时编译，还是全系统编译，都是轻松的事情拉。
虽然windows 平台和unix 平台差别很大，c++和java的差异也很大，但是如果大家将以上要求都用函数实现。我想迁移还是很方便的。1 t" v+ t  U' U* `" N% ~. L
尤其是脚本语言，多数是支持跨平台的。
2 _* W: V3 t/ Q0 _0 C' q/ k" @) j) T& m这里主要可能碰到的问题是。7 r8 O- u! R2 t6 B% @
1、模块结构规划不合理。
: ?# j  z: ?' |* g. |0 w. T* E9 n  m2、公共调用文件的安装问题。
3、模块编译顺序的问题。对于复杂的系统，那么调用关系就决定了编译顺序，可能要多次调整。
4、编译结果的安装问题。最好是编译完成通知测试人员，让他们自己安装。否则你自动杀掉他们正在测试的进程，他们会找你算账的。( k/ |( ?$ e' {$ T: q
5、编译结果的分析问题。编译结果的分析就需要自己写正则表达式来分析日志了，级联编译中是无法通过失败信号获取编译失败的，只能分析日志。
6、邮件发送问题。unix 平台，配置好DNS和sendmail就好啦，windows平台，如果没有找到你所用脚本语言的邮件发送函数，那么你就的自己用telnet 加 smtp 协议实现拉。- h5 F! e" h1 R3 N% F5 e

6 `! g" j" Q- l$ f, U8 ^) W0 @# y# y可能有人奇怪我为什么要设计一个数据出来，我想如果有数据库的话，方便维护人员根据编译目标文件的特征串，查找出，这是那一次编译的，生成他的源码有那些，具体版本是什么。/ n3 i& _+ p9 n5 N) V& D  w
同时也可以查找出是为那个需求或BUG而修改代码的，修改了那些地方等。同时也可以通过数据库统计，分析出，模块代码的变更情况和工作量，进度等。8 W/ |; s& w& x* v( |
同时也可以分析出那些人老是提交错，经常容易犯那些错误，编译流程改进，作为cmmi 5级的数据提供。1 P/ e5 r$ D8 u0 j7 x' q' R0 ?
拉拉杂杂写啦一大堆，希望对大家有用。

看到论坛里面有很多人询问，工具的选择和使用问题。个人建议：如果没有采购的想法。那么我建议使用SVN做版本管理工具。理由如下：
一、SVN的开发团队就是当初CVS的开发团队。( q3 "9 K- W( V" O* i/ n/ S" D
1、正式由于CVS的很多缺陷，所以才放弃CVS，改开发SVN的。
2、CVS以后只会修改BUG，不会在出新功能拉。
3、CVS的权限功能很不完全，犹如鸡肋。
二、SVN相对于CVS有很多优点。) o+ p; C1 M3 f
SVN的优点如下：
1、天然支持web。SVN服务器是可以和apache集成的，所以天然就支持HTTP协议，就可以通过互联网访问，同时可以使用apache的权限系统。而CVS只能通过CVSWEB来通过浏览器访问。4 ^1 h3 V2 ]0 P( Z# [  q, `; "$ q
2、SVN支持文件的移动，支持文件的改名，支持目录版本。
3、SVN提供拉API，提供拉各种语言的开发库，这个是CVS所不支持的。CVS的二次开发，只能通过命令行的方式做脚本，否则你就要在CVS的C代码中做接口，才能增加或修改功能。
4、SVN便于和自己开发的配置管理工具集成。原因如上。8 |3 g7 P  o/ _
5、SVN可以通过LDAP和公司的域结合起来，实现单点认证。
三、相对于CVS和SVN，VSS有几个个很大的缺点。
1、VSS是基于CHECKOUT、锁模式的，而SVN和CVS及基于CHECKOUT、合并模式的。后者显然更适合协同开发，适合多人修改同一份代码。而且作为配置管理员，也不用疲于奔命的去删除锁。
2、VSS只支持windows平台，而CVS和SVN是跨平台的。也许一时无所谓，但是如果有一天公司转向类unix平台，你就得迁移配置库，重新编写使用手册，并且做培训，为什么不把问题消灭在萌芽状态呢。* }0 x4 `" `4 e2 `7 Q5 `% _
3、VSS是要共享目录以便访问。这样在网络病毒猖獗的日子里，你就和病毒做斗争去吧。同时代码安全和是一个大问题啊。
4、VSS是不支持web访问的。9 V5 b: _" E1 U# ?1 X" o
5、权限配置也不够友好。" S. y$ J, X8

我想如果看过《Git历险记》的前面三篇文章的朋友可能已经知道怎么用git add，git commit这两个命令了；知道它们一个是把文件暂存到索引中为下一次提交做准备，一个创建新的提交（commit）。但是它们台前幕后的一些有趣的细节大家不一定知晓，请允许我一一道来。

Git 索引是一个在你的工作目录（working tree）和项目仓库间的暂存区域(staging area)。有了它, 你可以把许多内容的修改一起提交(commit)。 如果你创建了一个提交(commit)，那么提交的一般是暂存区里的内容, 而不是工作目录中的内容。

一个Git项目中文件的状态大概分成下面的两大类，而第二大类又分为三小类：

1. 未被跟踪的文件（untracked file）
2. 已被跟踪的文件（tracked file）
   1. 被修改但未被暂存的文件（changed but not updated或modified）
   2. 已暂存可以被提交的文件（changes to be committed 或staged）
   3. 自上次提交以来，未修改的文件(clean 或 unmodified)

看到上面的这么多的规则，大家早就头大了吧。老办法，我们建一个Git测试项目来试验一下：

我们先来建一个空的项目：

$rm -rf stage_proj

$mkdir stage_proj

$cd stage_proj

$git init

Initialized empty Git repository in /home/test/work/test_stage_proj/.git/

我们还创建一个内容是“hello, world”的文件：

$echo "hello,world" > readme.txt

现在来看一下当前工作目录的状态，大家可以看到“readme.txt”处于未被跟踪的状态（untracked file）：

$git status

# On branch master

#

# Initial commit

#

# Untracked files:

#   (use "git add <file>..." to include in what will be committed)

#

#   readme.txt

nothing added to commit but untracked files present (use "git add" to track)

把“readme.txt"加到暂存区： $git add readme.txt

现在再看一下当前工作目录的状态：

$git status

# On branch master

#

# Initial commit

#

# Changes to be committed:

#   (use "git rm --cached <file>..." to unstage)

#

#   new file:   readme.txt

#

可以看到现在"readme.txt"的状态变成了已暂存可以被提交（changes to be committed），这意味着我们下一步可以直接执行“git commit“把这个文件提交到本地的仓库里去了。

暂存区（staging area）一般存放在“git目录“下的index文件（.git/index）中，所以我们把暂存区有时也叫作索引（index）。索引是一个二进制格 式的文件，里面存放了与当前暂存内容相关的信息，包括暂存的文件名、文件内容的SHA1哈希串值和文件访问权限，整个索引文件的内容以暂存的文件名进行排 序保存的。

但是我不想马上就把文件提交，我想看一下暂存区（staging area）里的内容，我们执行git ls-files命令看一下：

$git ls-files --stage

100644 2d832d9044c698081e59c322d5a2a459da546469 0   readme.txt

我们如果有看过上一篇文章里 的"庖丁解牛", 你会发现“git目录“里多出了”.git/objects/2d/832d9044c698081e59c322d5a2a459da546469”这 么一个文件，再执行“git cat-file -p 2d832d” 的话，就可以看到里面的内容正是“hello,world"。Git在把一个文件添加暂存区时，不但把它在索引文件(.git/index)里挂了号，而 且把它的内容先保存到了“git目录“里面去了。

如果我们执行”git add“命令时不小心把不需要的文件也加入到暂存区中话，可以执行“git rm --cached filename" 来把误添加的文件从暂存区中移除。

现在我们先在"readme.txt"文件上做一些修改后：

$echo "hello,world2" >> readme.txt

再来看一下暂存区的变化:

$git status

# On branch master

#

# Initial commit

#

# Changes to be committed:

#   (use "git rm --cached <file>..." to unstage)

#

#   new file:   readme.txt

#

# Changed but not updated:

#   (use "git add <file>..." to update what will be committed)

#   (use "git checkout -- <file>..." to discard changes in working directory)

#

#   modified:   readme.txt

#

大家可以看到命令输出里多了一块内容：“changed but not updated ...... modified: readme.txt”。大家可能会觉得很奇怪，我前面不是把"readme.txt"这个文件给添加到暂存区里去了吗，这里怎么又提示我未添加到暂存区 （changed but not updated）呢，是不是Git搞错了呀。

Git 没有错，每次执行“git add”添加文件到暂存区时，它都会把文件内容进行SHA1哈希运算，在索引文件中新加一项，再把文件内容存放到本地的“git目录“里。如果在上次执行 “git add”之后再对文件的内容进行了修改，那么在执行“git status”命令时，Git会对文件内容进行SHA1哈希运算就会发现文件又被修改了，这时“readme.txt“就同时呈现了两个状态：被修改但未 被暂存的文件（changed but not updated），已暂存可以被提交的文件（changes to be committed）。如果我们这时提交的话，就是只会提交第一次“git add"所以暂存的文件内容。

我现在对于“hello,world2"的这个修改不是很满意，想要撤消这个修改，可以执行git checkout这个命令：

$git checkout -- readme.txt

现在再来看一下仓库里工作目录的状态：

$git status

# On branch master

#

# Initial commit

#

# Changes to be committed:

#   (use "git rm --cached <file>..." to unstage)

#

#   new file:   readme.txt

#

好的，现在项目恢复到我想要的状态了，下面我就用git commit 命令把这个修改提交了吧：

$git commit -m "project init"

[master (root-commit) 6cdae57] project init   1 files changed, 1 insertions(+), 0 deletions(-)    create mode 100644 readme.txt

现在我们再来看一下工作目录的状态：

$git status

# On branch master

nothing to commit (working directory clean)

大家可以看到“nothing to commit (working directory clean)”；如果一个工作树（working tree）中所有的修改都已提交到了当前分支里（current head），那么就说它是干净的（clean），反之它就是脏的(dirty)。

SHA1值内容寻址

正如Git is the next Unix 一文中所说的一样，Git是一种全新的使用数据的方式（Git is a totally new way to operate on data）。Git把它所管理的所有对象（blob，tree，commit，tag……），全部根据它们的内容生成SHA1哈希串值作为对象名；根据目 前的数学知识，如果两块数据的SHA1哈希串值相等，那么我们就可以认为这两块数据是相同 的。这样会带来的几个好处：

1. Git只要比较对象名，就可以很快的判断两个对象的内容是否相同。
2. 因为在每个仓库（repository）的“对象名”的计算方法都完全一样，如果同样的内容存在两个不同的仓库中，就会存在相同的“对象名”。
3. Git还可以通过检查对象内容的SHA1的哈希值和“对象名”是否匹配，来判断对象内容是否正确。

我们通过下面的例子，来验证上面所说的是否属实。现在创建一个和“readme.txt“内容完全相同的文件”readme2.txt“，然后再把它提交到本地仓库中：

$echo "hello,world" > readme2.txt

$git add readme2.txt

$git commit -m "add new file: readme2.txt"

[master 6200c2c] add new file: readme2.txt

1 files changed, 1 insertions(+), 0 deletions(-)

create mode 100644 readme2.txt

下面的这条很复杂的命令是查看当前的提交（HEAD）所包含的blob对象：

$git cat-file -p HEAD | head -n 1 | cut -b6-15 | xargs git cat-file -p

100644 blob 2d832d9044c698081e59c322d5a2a459da546469    readme.txt

100644 blob 2d832d9044c698081e59c322d5a2a459da546469    readme2.txt

我们再来看看上一次提交（HEAD^）所包含的blob对象：

$git cat-file -p HEAD^ | head -n 1 | cut -b6-15 | xargs git cat-file -p

100644 blob 2d832d9044c698081e59c322d5a2a459da546469    readme.txt

很明显大家看到尽管当前的提交比前一次多了一个文件，但是它们之间却是在共用同一个blob对象：“2d832d9”。

No delta, just snapshot

Git 与大部分你熟悉的版本控制系统，如Subversion、CVS、Perforce 之间的差别是很大的。传统系统使用的是： “增量文件系统” （Delta Storage systems），它们存储是每次提交之间的差异。而Git正好与之相反，它是保存的是每次提交的完整内容（snapshot）；它会在提交前根据要提交 的内容求SHA1哈希串值作为对象名，看仓库内是否有相同的对象，如果没有就将在“.git/objects"目录创建对应的对象，如果有就会重用已有的 对象，以节约空间。

下面我们来试验一下Git是否真的是以“snapshot”方式保存提交的内容。

先修改一下"readme.txt"，给里面加点内容，再把它暂存，最后提交到本地仓库中：

$echo "hello,world2" >> readme.txt

$git add readme.txt

$git commit -m "add new content for readme.txt"

[master c26c2e7] add new content for readme.txt   1 files changed, 1 insertions(+), 0 deletions(-)

我们现在看看当前版本所包含的blob对象有哪些：

$git cat-file -p HEAD | head -n 1 | cut -b6-15 | xargs git cat-file -p

100644 blob 2e4e85a61968db0c9ac294f76de70575a62822e1    readme.txt

100644 blob 2d832d9044c698081e59c322d5a2a459da546469    readme2.txt

从上面的命令输出，我们可以看到"readme.txt"已经对应了一个新的blob对象：“2e4e85a”，而之前版本的"readme.txt“对应的blob对象是：“2d832d9”。下面我们再来看一看这两个”blob“里面的内容和我们的预期是否相同：

$git cat-file -p 2e4e85a

hello,world

hello,world2

$git cat-file -p 2d832d9

hello,world

大家可以看到，每一次提交的文件内容还是全部保存的（snapshot）。

小结

Git内在机制和其它传统的版本控制系统（VCS）间存在本质的差异，所以Git的里"add"操作的含义和其它VCS存在差别也不足为奇，“git add“不但能把未跟踪的文件（untracked file）添加到版本控制之下，也可以把修改了的文章暂存到索引中。

同时，由于采用“SHA1哈希串值内容寻值“和”快照存储（snapshot）“，让Git成为一个速度非常非常快的版本控制系统（VCS）。

参考

• GitCommunityBook 中文版
• ProGit 中文版

致谢

感谢上帝对我的眷顾，让我可以有写作专栏的这样一个机会。

感谢朋友们在写作过程的无私帮助：张凯峰，刘炜，许晓斌，Fenng……

特别要感謝家人默默支持：）

原文：http://www.infoq.com/cn/news/2011/03/git-adventures-index-commit

如果我们要把一个项目加入到Git的版本管理中，可以在项目所在的目录用git init命令建立一个空的本地仓库，然后再用git add命令把它们都加入到Git本地仓库的暂存区（stage or index）中，最后再用git commit命令提交到本地仓库里。

创建一个新的项目目录，并生成一些简单的文件内容：

$ mkdir test_proj

$ cd test_proj

$ echo “hello,world” > readme.txt

在项目目录创建新的本地仓库，并把项目里的所有文件全部添加、提交到本地仓库中去：

$ git init #在当前的目录下创建一个新的空的本地仓库

Initialized empty Git repository in /home/user/test_proj/.git/

$ git add . #把前目录下的所有文件全部添加到暂存区

$ git commit -m 'project init' #创建提交

[master (root-commit) b36a785] project init

1 files changed, 1 insertions(+), 0 deletions(-)

create mode 100644 readme.txt

Git目录的结构

git init命令在项目的顶层目录中建了一个名为：“.git”的目录，它的别名是 “Git目录”（Git directory）。这时”Git目录”中虽然有一些文件，但是没有任何提交（commit）在里面，所以我们叫它是空仓库（empty Git repository）。

和 SVN不同，一个Git项目一般只在项目的根目录下建一个“.git”目录，而SVN则会在项目的每一个目录下建一个”.svn”目录；这也我喜欢Git的原因之一：）

Git把所有的历史提交信息全部存储在“Git目录”里，它就是一个Git项目的仓库；你对本地的源代码进行编辑修改后创建的提交也都会先保存在这 里面，然后再推送到远端的服务器。当我们我把项目目录和“Git目录”一起拷到其它电脑里，它能马上正常的工作（所有的提交信息全都保存在Git目录 里）；甚至可以只把“Git目录”拷走也行，但是要再签出（checkout）一次。

Git为了 调试的方便，它可以指定项目的Git目录的位置。有两种办法：一是设置“GIT_DIR”环境变量，二是在命令行里设定“--git-dir--git-dir”参数指定它的位置，大家可以看一下这里(git(1) Manual Page)。

庖丁解牛

前面的这些东东我在第一篇里也大概的讲过一些，但是今天我们想不但要开动这辆叫“Git”的跑车，还想看看它里面有些什么样的零件，是怎么构成的。

OK，我们来看看“test_proj”项目里的“Git目录”的结构：

$cd test_proj/.git

$ ls | more

branches/ # 新版的Git已经不再使用这个目录，所以大家看到它 #一般会是空的

COMMIT_EDITMSG # 保存着上一次提交时的注释信息

config # 项目的配置信息

description # 项目的描述信息

HEAD # 项目当前在哪个分支的信息

hooks/ # 默认的“hooks” 脚本文件

index # 索引文件，git add 后把要添加的项暂存到这里

info/ # 里面有一个exclude文件，指定本项目要忽略的文件 #，看一下这里

logs/ # 各个refs的历史信息

objects/ # 这个目录非常重要，里面存储都是Git的数据对象

# 包括：提交(commits), 树对象(trees)，二进制对象 #（blobs）,标签对象（tags）。

#不明白没有关系，后面会讲的。

refs/ # 标识着你的每个分支指向哪个提交（commit）。

我先用git log命令来看一下这个Git项目里有哪些提交：

$ git log

commit 58b53cfe12a9625865159b6fcf2738b2f6774844

Author: liuhui998 <liuhui998@nospam.com>

Date: Sat Feb 19 18:10:08 2011 +0800

project init

大家可以看到目前只有一个提交（commit）对象，而它的名字就 是：”58b53cfe12a9625865159b6fcf2738b2f6774844”。这个名字就是对象内容的一个SHA签名串值，只要对象里面 的内容不同，那么我们就可以认为对象的名字不会相同，反之也成立。我在使用时一般不用把这个40个字符输全，只要把前面的5~8个字符输完就可以（前提是 和其它的对象名不冲突）。为了方便表示，在不影响表达的情况下，我会只写SHA串值的前6个字符。

我们可以用git cat-file来看一下这个提交里的内容是什么:

$ git cat-file -p 58b53c

tree 2bb9f0c9dc5caa1fb10f9e0ccbb3a7003c8a0e13

author liuhui998 <liuhui998@nospam.com> 1298110208 +0800

committer liuhui998 <liuhui998@nospam.com> 1298110208 +0800

project init

大家可以看到：提交“58b53c” 是引用一个名为“2bb9f0”的树对象（tree）。一个树对象（tree）可以引用一个或多个二进制对象（blob）, 每个二进制对象都对应一个文件。 更进一步, 树对象也可以引用其他的树对象，从而构成一个目录层次结构。我们再看一下这个树对象（tree）里面有什么东东：

$ git cat-file -p 2bb9f0

100644 blob 2d832d9044c698081e59c322d5a2a459da546469 readme.txt

不难看出，2bb9f0”这个树对象（tree）包括了了一个二进制对象（blob），对应于我们在前面创建的那个叫 ”readme.txt”的文件。现在我们来看看这个”blob”里的数据是不是和前面的提交的内容一致：

$ git cat-file -p 2d832d

hello,world

哈哈，熟悉的“hello,world”又回来了。

想不想看看提交对象、树对象和二进制对象是怎么在”Git目录“中存储的；没有问题，执行下面的命令，看看”.git/objects”目录里的内容：

$ find .git/objects

.git/objects

.git/objects/2b

.git/objects/2b/b9f0c9dc5caa1fb10f9e0ccbb3a7003c8a0e13

.git/objects/2d

.git/objects/2d/832d9044c698081e59c322d5a2a459da546469

.git/objects/58

.git/objects/58/b53cfe12a9625865159b6fcf2738b2f6774844

.git/objects/info

.git/objects/pack

如果大家仔细看上面命令执行结果中的粗体字，所有的对象都使用SHA签名串值作为索引存储在”.git/objects”目录之下；SHA串的前两个字符作为目录名，后面的38个字符作为文件名。

这些文件的内容其实是压缩的数据外加一个标注类型和长度的头。类型可以是提交对象（commit）、二进制对象（blob）、 树对象（tree）或者标签对象（tag）。

如何clone一个远程项目

我身边的很多朋友是因为要得到某个开源项目的代码，所以才开始学习使用Git。而获取一个项目的代码的一般的做法就是用git clone命令进行直接复制。

例如，有些朋友可能想看一下最新的linux内核源代码，当我们打开它的网站时，发现有如下面的一段提示：

URL

git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

URL下面的三行字符串表示三个地址，我们可以通过这三个地址得到同样的一份Linux内核源代码。

也就是说下面这三条命令最终得到的是同一份源代码：

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

git clone http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

git cone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

我们先来看一下URL，git://、http://、https://这些代表是传输git仓库的协议形式，而“git.kernel.org“则代表了Git仓库存储的服务器名字（域名），“/pub/scm/linux/kernel/git/torvalds/linux-2.6.git” 则代表了Git仓库在服务器上位置。

Git 仓库除了可以通过上面的git、http、https协议传输外还可以通过ssh、ftp(s)、rsync等协议来传输。git clone的本质就是把“Git目录”里面的内容拷贝过来，大家想想看，一般的“Git目录”里有成千上万的各种对象（提交对象，树对象，二进制对象......)，如果逐一复制的话，其效率就可想而知。

如果通过git、ssh协议传输，服务器端会在传输前把需要传输的各种对象先打好包再进行传输；而http（s）协议则会反复请求要传输的不同对 象。如果仓库里面的提交不多的话，前者和后者的效率相差不多；但是若仓库里有很多提交的话，git、ssh协议进行传输则会更有效率。

不过现在Git对http（s）协议传输Git仓库做了一定的优化，http（s）传输现在也能达到ssh协议的效率，有兴趣的朋友可以看一下这里（Smart HTTP Transport）。

好的，现在我们执行了下面这条命令，把linux-2.6的最新版源代码clone下来：

$cd ~/

$mkdir temp

$git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

Initialized empty Git repository in /home/liuhui/temp/linux-2.6/.git/

remote: Counting objects: 1889189, done.

remote: Compressing objects: 100% (303141/303141), done.

Receiving objects: 100% (1889189/1889189), 385.03 MiB | 1.64 MiB/s, done.

remote: Total 1889189 (delta 1570491), reused 1887756 (delta 1569178)

Resolving deltas: 100% (1570491/1570491), done.

Checking out files: 100% (35867/35867), done.

当我们执行了“git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git”这条命令后大家可以看到这条输出：

Initialized empty Git repository in /home/user/temp/linux-2.6/.git/

这就是意味着我们在本地先建了一个“linux-2.6”目录，然后在这个目录建了一个空的Git本地仓库（Git目录）；里面将会存储从网上拉下来的历史提交。

下面两条输入代表服务器现在调用 git-pack-objects 对它的仓库进行打包和压缩：

remote: Counting objects: 1888686, done.

remote: Compressing objects: 100% (302932/302932), done.

然后客户端接收服务器端发过送过来的数据：

Receiving objects: 100% (1889189/1889189), 385.03 MiB | 1.64 MiB/s, done.

在我们执行完上面的clone linux-2.6代码的的操作后，Git会从“Git目录”里把最新的代码到签出（checkout）到“linux-2.6”这个目录里面。我们一般 把本地的“linux-2.6”这个目录叫做”工作目录“（work directory），它里面保存着你从其它地方clone（or checkout）过来的代码。当你在项目的不同分支间切换时，“工作目录”中的文件可能会被替换或者删除；“工作目录”只是保存着当前的工作，你可以修 改里面文件的内容直到下次提交为止。

大家还记得前面的“庖丁解牛”吗，是不是觉得只杀一头叫“hello,world”的小牛太不过瘾了。没有问题，拿起前面的那把小刀，来剖析一下现在躺在你硬盘里这头叫“linux-2.6”大牛看看，我想一定很好玩。

在写篇文章的过程中，我要感谢在那些关心我并提出真诚意见的朋友，如果没有你们真诚的意见，我也许没有这么强烈的紧迫感，也不会深深的感到自己的不足。我是第一次写专栏，张凯锋同学给了我很大的帮助。最后还是要感谢我的家人，是他们让我有时间来进行写作：）

原文：http://www.infoq.com/cn/news/2011/02/git-adventures-local-repository

从这一篇开始，我就将比较“啰嗦”的和大家一起从零开始经历Git使用的每一步，当然对我而言这也是一个重新认识Git的过程。

使用Git的第一步肯定是安装Git，因为在多数平台上Git是没有预装的。我平时主要的工作环境是windows和Linux（ubuntu），我想看这篇文章的同学多半也是在这两个平台下工作；下面我讲一下如何在这两个平台下安装和配置Git。

BTW:如果是苹果平台的用户的安装可以参看一下这里(1,2)，配置和命令行的使用与windows、Linux（*nix）平台差别不大。

Linux (*nix) 平台

Linus开发Git的最初目的就是为了开发Linux内核服务的，自然它对Linux的平台支持也是最棒的。在Linux下安装Git大约有几种方法：

从源代码开始(这种方法也适合于多数*nix平台)

从Git官网的下载页面下载它最新稳定版的源代码，就可以从源代码开始编译、安装：

$ wget http://kernel.org/pub/software/scm/git/git-1.7.3.5.tar.bz2

$ tar -xjvf git-1.7.3.5.tar.bz2

$ cd git-1.7.3.5

$ make prefix=/usr all ;# prefix设置你的Git安装目录

$ sudo make prefix=/usr install ;# 以root权限运行

为了编译Git的源代码，我们还需要一些库: expat、curl、 zlib 和 openssl； 除了expat 外，其它的库可能在你的机器上都安装了。

使用安装包管理器（apt 或 yum）

在 fedora 等系统下用yum ：

$ yum install git-core 

在debian, ubuntu等系统下用apt ：

$ apt-get install git-core

有时候，你系统里的安装包管理器出现了问题，或是要安装Git的机器不能上网、没有编译器的话，你可以从下面的站点去下载 “.deb” 或 “.rpm”的安装包：

• RPM Packages
• Stable Debs

Windows平台

windows平台有两个模拟*nix like运行环境的工具：cygwin，msys；Git在cygwin，msys下都有相应的移植版本。我个人觉得msys平台下的msysGit最好用，现在我在windows下也是用的这个版本。

很多同学可能要问，现在windows下有那多Git用户，为什么Git不直接出一个windows native版。俺当年翻看了一下Git的源代码，它里面使用了大量的*nix平台的native api，而这些api在windows下是没有的，所以必须要用cygwin、msys这样的一个中间层来满足软件移植的要求。

下面我“啰嗦”一下如何在windows下安装msysGit。

下载

到它的下载页面去下载一个最新的完整安装包，笔者在撰写本文时下载的是这个。

安装

安装的过程没有什么好说的，一般是开始安装后，一路的点击“下一步”。由于windows平台的换行符（CRLF）和Linux(*nix)平台的换行符（LF）不同，那么在windows下开发其它平台软件的朋友有一个地方要注意（见下图)：

在这里一最好选“Checkout as-is, commit as-is”这个选项，这样，Git就不会修改你代码的换行符风格。

以前有个朋友因为选错了这个选项，以致他在windows平台下的一签出（checkout）其它平台的代码，就会显示”已修改“（modified），不过后来可能msysGit也认识到这个问题了，就把默认选项改成了这个选项。

BTW: 其实前面两项也是有用的，如果对windows和Linux(*nix)平台如何处理换行符很熟悉的话，也可以尝试一下前面两个选项：）

配置Git

在Linux下和windows下配置Git的方法差不多，只是在Linux下，可以在命令行里直接使用git config进行配置, 而在windows下则要先打开“Git Bash”，进入msysGit命令行界面，再用git config命令进行相应的配置操作。

好了，前面安装好了Git，现在我们开始配置：

第一个需要配置的就是用户的用户名和email，因为这些内容会出现在你的每一个提交（commit）里面的，像下面这样：

$ git log #我们用git log查看当前仓库的提交（commit）日志

commit 71948005382ff8e02dd8d5e8d2b4834428eece24

Author: author <author@corpmail.com>

Date: Thu Jan 20 12:58:05 2011 +0800

Project init

下面的这两行命令就是设置用户名和email：

$ git config --global user.name author #将用户名设为author

$ git config --global user.email author@corpmail.com #将用户邮箱设为author@corpmail.com

Git的配置信息分为全局和项目两种，上面命令中带了“--global"参数，这就意味是在进行全局配置，它会影响本机上的每个一个Git项目。

大家看到，上面我们用的是@corpmail（公司邮箱）；但是有时候我们可能也参与了一些开源项目，那么就需要新的用户名和自己的私人邮箱，Git 可以为每个项目设定不同的配置信息。

在命令行环境，进入Git项目所在目录，执行下面的命令：

$ git config　user.name nickname#将用户名设为nickname

$ git config　user.email nickname@gmail.com #将用户邮箱设为nickname@gmail.com

Git的设计哲学和Linux（*nix）一样，尽量的使用“文本化”（Textuality）；它里面尽量用文本化的形式存储信息，对于配置信息也更是如此，用户的这些配置信息全部是存储在文本文件中。Git的全局配置文件是存放在"~/.gitconfig"（用户目录下的.gitconfig）文件中：

我们用cat、head命令查看全局配置信息文件，并假设相关配置信息存储在文件的前3行（当然也有可能不在前3行，这里只是为了方便表示）

$ cat ~/.gitconfig | head -3 

[user]

name = author

email = author@corpmail.com

而项目配置文件是存放在Git项目所在目录的".git/config"文件中，这里也像上面一样用cat、head命令查看一下：

$ cat .git/config | head -3

[user]

name = nickname

如果大家对于Git熟悉后，可以直修改”~/.gitconfig”,”.git/config”这两个文件进行配置。

Git里还有很多可以配置的地方，大家可以参考一下git config 和 定制git。

这一篇写起来有点平淡无奇，但这是一个Git用户迈出的第一步。后面我还会有一系列的文章出来，都是我个人使用过程中的感悟。

有朋友问我：“为什么把文章叫作：‘Git历险记’”。这是因为在使用Git的历程中，我碰到过N多的问题；同时也觉得它有点小复杂。但是当这些问题解开后，就有时不得不赞叹它设计的巧妙之处。

如果大家对于我的文章有什么问题和建议，欢迎给我写邮件：

之前我建立了一个 git中文用户组 ，如果大家在使用Git的过程中碰到什么麻烦事，欢迎你在这个用户组里提问。

参考资料：

• GitCommunityBook 中文版
• ProGit 中文版
• git config

感谢张凯峰对本文的策划及无比耐心的审校。

感谢家人在我的写作过程中的默默支持。

原文：http://www.infoq.com/cn/news/2011/01/git-adventures-install-config

email = nickname@gmail.com

Git是Linus.Torvald为了管理Linux内核发起并开发的一个开源分布式版本控件系统（DVCS）。从2002年起，Linux 内核一直使用BitKeeper来进行版本管理，但是在2005年BitKeeper和Linux 内核开源社区的合作关系结束，BitKeeper再也不能免费使用了，这迫使Linus决定开发一个开源界自已的版本控制系统。

传统的SVN、CVS 等版本控制系统，只有一个仓库（repository)，用户必须要连上这个仓库才能开始提交；而Git之类的分布式版本控制系统（当然也还包括 BitKeeper、Mercurial等 等），它的每个工作目录都包含一个完整的仓库，它们可以支持离线工作，先把工作提交到本地仓库后再提交上远程的服务器上的仓库里。分布式的处理也让开发更 为便捷，开发人员可以很方便的在本地创建分支来进行日常开发，每个人的本地仓库都是平等且独立，不会因为你的本地提交而直接影响别人。

老实说，Git的速度是我用的版本控制系统中最快的（SVN Mercurial Git）。我这里说的速度，包括本地提交(commit)、本地签出(checkout)、提交到远程仓库(git push)和从远程仓库获取（git fetch ，git pull）；它的本地操作速度和本地文件系统在一个级别，远程仓库的操作速度和SFTP文件传输在一个级别。这当然和Git的内部实现机制有关，这里就不 多展开了，有兴趣的朋友可以看一下这里：Git is the next Unix。

我们在学一门新的语言时，往往是从一个“hello world” 程序开始的，那么Git历程也就从一个“hello Git”开始吧。

在这里假设各位同学的电脑都装好了Git，如果没有装好，可以先看一下这里（安装Git）。当然，后面的章节我会专门讲安装可能会碰到的问题。

我们首先打开Git的命令行：windows下是点击“Git Bash 快捷方式”；Linux或是Unix like平台的话就直接打开命令行界面就可以了。

备注：$符号后面的字符串代表的是命令行输入；命令行输入后的以#开始的黑体字符串代表注释；其它的部分则是命令行输出。

我们先用建一个仓库吧：

$mkdir testGit #建立仓库目录







$cd testGit #进入仓库目录







$git init #这会在当前的目录下建一个仓库







Initialized empty Git repository in e:/doc/Git/test/testGit/.git/ 

好的，前面的三行命令就建立了一个本地的Git仓库。这个仓库现在是一个空的仓库。

我们在命令行下执行：

$ git status #查看当前仓库的状态







# On branch master (在master分支上) 







# 







# Initial commit 







# 







nothing to commit (create/copy files and use "git add" to track) 







(现在没有任何台被提交的文件，复制或创建新的文件，再用”git add” 命令添加到暂存区中) 







$ git log #查看当前仓库的历史日志







fatal: bad default revision 'HEAD'







(由于仓库里没有任提交在里面，所以它会报这个错。BTW: 这种提示是不是有点不友好呀：) ) 

现在就让我们在这个仓库里添加点内容吧。

$ echo “hello Git” > readme.txt #建立一个含有 hello Git 的文本文件







$ git add readme.txt #将readme.txt添加到暂存区中







$ git status #查看当前仓库的状态 







# On branch master 







# 







# Initial commit 







# 







# Changes to be committed:(暂存里下次将被提交的修改) 







# (use "git rm --cached <file>..." to unstage) 







# 







# new file: readme.txt 







# 

好的，文件即然被暂存到暂存区中，我们现在就可以把它提交到仓库里面去：）

$ git commit -m "project init" #将刚才的修改提交到本地仓库中 







[master (root-commit) 8223db3] project init 







1 files changed, 1 insertions(+), 0 deletions(-) 







create mode 100644 readme.txt 







$ git status 







# On branch master 







nothing to commit (working directory clean) 







(现在这个工作目录里没有什么要提交的东东，它是整洁的) 

现在你执行一下git log 命令就会看到刚才的提交记录

$ git log 







commit 8223db3b064a9826375041c8fea020cb2e3b17d1 







Author: liuhui998 <liuhui998@gmail.com> 







Date: Sat Jan 1 18:12:38 2011 +0800 







project init 

“8223db3b064a9826375041c8fea020cb2e3b17d1”这一串字符就是我们这次创建的提交的名字。看起来是不是很 熟，如果经常用电驴的朋友就会发现它就是和电驴里内容标识符一样，都是SHA1串。Git通过对提交内容进行 SHA1 Hash运算，得到它们的SHA1串值，作为每个提交的唯一标识。根据一般的密码学原理来说，如果两个提交的内容不相同，那么它们的名字就不会相同；反 之，如果它们的名字相同，就意味着它们的内容也相同。

现在我想改一下仓库里文件的内容，现提交到仓库中去

$ echo "Git is Cool" >> readme.txt #在文件的最后添加一行 







$ git status #查看当前仓库的状态 







# On branch master 







# Changed but not updated: (修改了，但是还没有暂存的内容) 







# (use "git add <file>..." to update what will be committed) 







# (use "git checkout -- <file>..." to discard changes in working directory) 







# 







# modified: readme.txt 







# 







no changes added to commit (use "git add" and/or "git commit -a") 







(没有修改可以被提交，使用 “git add” 命令添加文件到暂存区，或是使用“git commit -a” 命令强制提交当前目录下的所有文件)

OK，即然我们修改了仓库里被提交的文件，那么我想看一下我们

到底改了哪些地方，再决定是否提交。

$ git diff #查看仓库里未暂存内容和仓库已提交内容的差异 







diff --git a/readme.txt b/readme.txt 







index 7b5bbd9..49ec0d6 100644 







--- a/readme.txt 







+++ b/readme.txt 







@@ -1 +1,2 @@ 







hello Git 







+Git is Cool 

很好，正如我们所愿，我们只是在readme.txt的最后一行添加了一行“Git is Cool”。

好的，我们现在再把 readme.txt放到暂存区里：

$ git add readme.txt 

我们现在看一下仓库的状态：

$ git status 







# On branch master 







# Changes to be committed: 







# (use "git reset HEAD <file>..." to unstage) 







# 







# modified: readme.txt 







# 

可以提交了：

$ git commit -m "Git is Cool" 







[master 45ff891] Git is Cool 







1 files changed, 1 insertions(+), 0 deletions(-) 







(一个文件被修改，一行插入，零行删除) 

再看一下新的日志：

$ git log 







commit 45ff89198f08365bff32364034aed98126009e44 







Author: liuhui998 <liuhui998@gmail.com> 







Date: Sat Jan 1 18:17:07 2011 +0800 







Git is Cool 







commit 8223db3b064a9826375041c8fea020cb2e3b17d1 







Author: liuhui998 <liuhui998@gmail.com> 







Date: Sat Jan 1 18:12:38 2011 +0800 















project init 

“45ff89198f08365bff32364034aed98126009e44” 这个就是我们刚才提交修改时创建的提交。

大家这么一路看过来，是不是有点糊涂了。不过没有关系，如果你的电脑装了Git，那么你把上面的这些命令全部执行一下遍就会对它有感性的认识了。

下面的的章节，我会讲一下如何在windows和Linux安装配置Git，以及需要注意的问题：）

原文：http://www.infoq.com/cn/news/2011/01/git-adventures-1

http://www.infoq.com/cn/git-adventures(Git )

定制Git

git config

更改你的编辑器

$ git config --global core.editor emacs

添加别名

$ git config --global alias.last 'cat-file commit HEAD'



$ git last

tree c85fbd1996b8e7e5eda1288b56042c0cdb91836b

parent cdc9a0a28173b6ba4aca00eb34f5aabb39980735

author Scott Chacon <schacon@gmail.com> 1220473867 -0700

committer Scott Chacon <schacon@gmail.com> 1220473867 -0700



fixed a weird formatting problem



$ git cat-file commit HEAD

tree c85fbd1996b8e7e5eda1288b56042c0cdb91836b

parent cdc9a0a28173b6ba4aca00eb34f5aabb39980735

author Scott Chacon <schacon@gmail.com> 1220473867 -0700

committer Scott Chacon <schacon@gmail.com> 1220473867 -0700



fixed a weird formatting problem

添加颜色

所有的color.*选项请参见git config的文档

$ git config color.branch auto

$ git config color.diff auto

$ git config color.interactive auto

原文：http://gitbook.liuhui998.com/5_7.html

$ git config color.status auto

或者你可以通过color.ui选项把颜色全部打开:

$ git config color.ui true

提交模板

$ git config commit.template '/etc/git-commit-template'

日志格式

$ git config format.pretty oneline

其他配置选项

除上面提到的选项外, 还有很多很有趣的选项去配置打包, 垃圾回收, 合并, 分支, http传输, diff, 分页, 空白字符等等的行为. 如果你需要更加深入地调教git, 请阅读git config文档.

安装Git

从源代码开始安装

如果你在一个其基于Unix的系统中，你可以从Git的官网上Git Download Page下载它的源代码,并运行像下面的几行命令,你就可以安装:

$ make prefix=/usr all ;# as yourself 

$ make prefix=/usr install ;# 以root权限运行

你需一些库: expat,curl, zlib, 和 openssl; 除了expat 外，其它的可能在你的机器上都安装了。

Linux

如果你用的是Linux，你可以用你的本地包管理系统(native package management system)来安装.

$ yum install git-core  #译者注，在redhat等系统下用yum



$ apt-get install git-core  #译者注，在debian, ubuntu等系统下用apt-get

如果你用上面的命令不起作用的话，你可以从下面两个站点下载 .deb 或 .rpm 包:

RPM Packages

Stable Debs

如果你在Linux兴趣从源代码开始安装的话,下面的这篇文章也许对你有帮助: Article: Installing Git on Ubuntu

Mac 10.4

在Mac10.4和 10.5,如果你安装了MacPorts,你可以通过 MacPorts来安装Git。如果你没有安装MacPort, 你可以从 这里来安装它.

当你安装好MacPorts后，你可通过下面的命令来安装:

$ sudo port install git-core

如果你想从源代码开始安装，下面这些文章可能对你有帮助:

Article: Installing Git on Tiger

Article: Installing Git and git-svn on Tiger from source

Mac 10.5

在Leopard系统下，你也可以通过MacPorts来安装,但是你有一个新的选项:"一个漂亮的安装包", 你可以从这里来下载:Git OSX Installer

如果你想从源代码开始安装，我希望下面些资料能对你有帮助:

Article: Installing Git on OSX Leopard

Article: Installing Git on OS 10.5

Windows

在Windows下安装Git是很简单的，你只要下载msysGit就可以了。

Git on Windows 这一章有一个"screencast"来在演示如何在windows下使用Git.

原文：http://gitbook.liuhui998.com/2_1.html

以前一直通过serv-u搭建FTP服务器，不过最近发现serv-u不是很好用，经常出现CPU资源占用过高的情况，所以考虑着更换一个FTP服务器软件。

这次更换的软件就是FileZilla Server啦！使用ubuntu的时候接触过这个软件的客服端版本，早知道他是开源免费的了，所以这次第一时间就想到了FileZilla Server

本来准备自己写教程的，图文都制作好好几张了，因为有的英文不了解，Google的时候发现了两个PDF文件，实在是比我的要好，我就不自己写了，直接套用别人的吧！

第一个是豆丁网的：FileZilla FTP Server安装设置教程

另外一个是“笑申的博客”：FileZilla FTP Server 使用手册（PDF教程下载）

引用如下：

FileZilla Server 使用手册（附PDF文档，可下载后观看）PDF下载：FileZilla_Server_Guide.pdf

一、简介

Filazilla 是一个非常流行的开源的免费的FTP客户端、服务器端的项目，目前其客户端软件Filezilla Client 3.0有着非常广泛的市场。
Filezilla 的主要优势在于：高安全、高性能。Filazilla的安全性是来自于其开放源代码的。开源为何能保证安全？每一款软件产品诞生后，都有很多人试图发现其 漏洞进行攻击，以获取权限和其他利益。如果是开源软件，攻击者就会下载这个软件的源代码，从源头上分析其内部漏洞在那里，并且进行攻击。开源的规模越大， 下载阅读其源代码的人也多，这个软件也就越普及。随着其逐渐改进，漏洞就越来越少，最后成为了公认极其安全的软件，这和互联网中数万程序员的贡献是分不开 的。这类软件的代表就是Linux平台下的Apache、PHP、MySQL、Bind、Vsftpd等大量高可靠性软件。而不开放源代码的闭源软件，人 们无法对其进行研究，因此，只能将他当作“黑盒”来研究，研究的过程中没有源代码，很难找到其错误。即便找到了一些错误，还有更多的漏洞隐藏在代码中，但 是因为代码不公开，因此人们短期内无从发现，后期使用会暴露出很多问题。一些闭源软件甚至保留有“后门”，以方便远程遥控，比如Windows，比如 Serv-U。而开源软件代码是开放的，如果开发者在里边植入“后门”等危险代码，就会被互联网上广大的程序员纠出来，因此，这里也可以看出，开源，是对 安全的最好保证。
Filezilla的高性能来自于其代码的开发平台是C/C++，自身基础就好于其他VB/Dephi平台开发的应用程序，因 此Filezilla具有可媲美IIS的性能。在千兆网络带宽上，可轻松满足数百用户同时高速下载。
目前Filezilla也存在一些不足，主 要缺点就是不支持配额，即本身不提供上传、下载总文件大小配额的功能。即便如此，免费的Filezilla正越来越多的占领原来Serv-U等软件的市 场，变得更加贴近用户了。

二、安装

安装过程非常简单，首先下载Filezilla Server安装文件，如果觉得去国外英文官方网站下载速度慢，也可以从这里下载：
下载地 址：http://www.swsoft.com.cn/temp/FileZilla_Server.exe
将安装包下载到桌面，准备安装。
双击安装程序开始安装。点击“I Agree”继续。
选择安装方式，默认的标准即可。其中“Source Code”源代码一般不用安装，除非是想研究FileZilla的代码。
选择安装路径，强烈推荐安装到非默认路径，以增加安全系数。例如如下路 径：
选择“安装为服务，并随机自动启动”的选项。下边的14147是管理端口，强烈推荐修改此端口，例如改成38121端口。（注意不要和常见 服务如80端口冲突）。
选择“当管理员登录时候，启动管理界面”的选项。
安装进行中。
至此安装完成，安装程序自动启动管理 控制台，默认是连接到本机的管理端口。管理端口到底是多少，请参考前文安装过程中填写的具体数字是多少。建议选中“总是连接到本服务器”的选项，即表示每 次启动管理控制台，都是管理本机的Filezilla服务。下边有一个输入密码的对话框，在里边输入本服务器Filezilla服务的密码。
注 意：修改端口和密码非常重要，这是确保Filezilla安全的重点，必须修改端口，必须设置密码！密码建议足够复杂！
点击OK后，即可启动初 始化之后的管理控制台，配置完成。

三、 配置

1. 基本设置

Filezilla默 认的模式是Port模式，不是Passive被动模式。为了解决防火墙后的客户端连接问题，最好是启用Passive模式。要启动被动模式，首先打开管理 控制台，点击左起第三个图标 进入系统设置。
点击左侧“Welcom message”菜单，即FTP登录后的欢迎信息。
为了安全起 见，强烈建议修改默认的欢迎信息为“Welcom to Serv-U FTP Server”，这样Filezilla在欢迎消息中就会Serv-U字样，以达到欺骗攻击者的目的。注意：本步骤非常重要！
现在我们用 telnet去连接一下FTP的21端口，即可看到修改过的“假”的提示信息，这样服务器的安全性可以得到比较明显的提高。
接下来点击 “Passive Mode Settings”选项，进入被动模式设置。
选中启动被动模式端口范围的选项，输入10000~10050端口范 围，表示被动模式将要使用这个范围的端口。
点击确定保存即可。接下来在防火墙上允许10000~10050端口范围进出，或者
直接允许 Filezilla server.exe主程序的互联网访问。
安装的最后一步是加固权限，找到Filezilla的配置文件，格式是xml格 式，鼠标右键点击之，并选择属性。
加入Guest组禁止读写的权限，设置为拒绝。
点击确定后，系统会弹出提示，询问拒绝权限优先级高 于允许权限，是否要继续，点击是通过即可。
至此初始化基本配置完成。

2. 匿名FTP配置

首先打开管理控 制台，点击左起第四个图标 进入系统设置。
打开ftp用户管理界面，点击右侧的 按钮，添加新用户。
在新增用户的对话框中，输入 “anonymous”这个名字，即FTP的匿名用户。
点击确认，添加用户完成，返回用户管理界面。
点击左侧的“Shared folders”菜单。点击Add按钮，添加一个目录。
打开浏览文件夹的选项，选择要设置FTP的目录。
点击确定，添加用户完成。
现 在用户FTP客户端连接到FileZilla Server上，可以看到匿名FTP已经配置完成。

3. 标准FTP用户配置

首 先进入用户设置界面，点击“Add”按钮添加新的FTP用户。
输入用户名test 。
选中Password前边的多选框，然后输入密 码123456。
返回到用户管理界面，点击设置文件夹目录，点击Add添加目录。
添加一个目录到test用户。
添加完成， 再右侧选中test用户对这个目录的权限，然后点击左侧的OK按钮，配置完成。
配置完成。现在可以使用客户端来测试登录了。
打开 FTP客户端软件，输入test用户名和密码123456，登录到服务器。
登录成功后，可以看到刚才制定的FTP目录下的文件，并具有相应的上 传、下载权限。

4. 虚拟目录配置

在具有多个目录需要共享的情况下，设置虚拟目录是比较利于管理的选择。通常，一个 FTP服务器需要有一个“Home”主目录，然后设置若干个虚拟目录。
首先进入到用户管理界面，选中Test用户，选中当前设置的目录。
点 击“Set as home dir”选项 ，将当前目录设置为“home”主目录。
点击Add按钮，在原有目录之外，再添加一个别的目录，比 如选择桌面目录。
新的目录已经添加到目录清单了。此时添加“别名”，点击“Alias”空白处。
添加Aliases别名，注意一定用 “ /”符号开头，表示是根目录下的虚拟目录。
添加完成。现在可以去登录FTP，就能看到虚拟目录了。
登录到FTP之后，可以看到虚 拟目录出现在test用户的目录中。
至此虚拟目录设置完成。

5. 加固Filezilla安全

• 安装Filezilla到非标准目录
• 安装过程中设置Filezilla的管理端口监听在127.0.0.1上的随机端口，例如38471等奇怪的没用的端口。
• 安装过程中设置Filezilla的管理密码，并设置密码足够复杂
• 在Filezilla目录下的xml配置文件上，设置Guests组禁止读取的权限
• 修改FTP登录后的提示信息为IIS、Serv-U等信息
• 不要开启SSL加密、SFTP等功能，避免以后出现漏洞
经过如上一些配 置，Filezilla可以做到很高的安全性。

原文： http://vv15.com/2010/05/filezilla-server-pdf/

fedora 8的安装过程

PS： 开始安装的是fedora 12,由于不是全部安装，很多东西没有自带（比如svn,比如samba,bison,）然后即使后来安装了，也仍然在编译的时候出现很多问题，编译不通过，接连搞了2天，都没有结果，于是今天安装了fedora 8,选择了软件开发，但是重启的时候出现停住不动的情况，这个没有关系，自己按键重启就好了。

fedora 8遇到的一些问题：

1.       ifconfig 命令找不到，是因为环境变量PATH里没有sbin 和/usr/sbin,补充进去即可。

2.       fedora 的相应信息：

ip:172.28.6.36

======================================================================

安装fedora（fedora 8）

我的fedora系统的IP：172.28.6.36

原本是windows系统没关系，使用光驱安装，电脑启动的时候按F2或其他某个键进入BIOS选择使用光驱启动就可以把原本是windows的系统安装成Fedora系统了。

dev/sda1

我的Fedora系统的信息记录：

Hostname: fedoraOfKiki

Root Password:82632955

PS：安装过程中，使用中文指示后面的安装

使用完全安装，把所有软件都勾上。

分区那一步，我选择Use entire drive，使用整个硬盘空间（即全部革掉了）

安装OK,重启，创建User(kiki,82632955)

su 切换用户

2.

在fedora中先安装samba服务器，安装方法如下：

yum update 更新源

yum –y install samba-swat

yum –y install bision

3.使用 tar jvxf tar包 直接将这个toolchain解到opt/toolchains/uclibc-mipsel-gcc-4.2.3下面

不管在哪里解压，只要将解压好的东西放在 /opt/toolchains/目录下面即可。

解压2个toolchains 到/opt目录下面

63281 toolchains：

http://10.58.100.247/svn_dsl/DSL/software/branch/4.02L.03_CT_ADSL_B/toolChains/uclibc-crosstools-gcc-4.2.3-3_LFS.tar.bz2

5358 toolchains：

http://10.58.100.247/svn_dsl/DSL/software/branch/4.02L.03_CT_ADSL_B_5358U/toolchain/uclibc-mipsel-gcc-4.2.3.tar.bz2

4.

发现fedora里面并没有自带svn,所以使用命令yum –y install svn进行安装，居然OK了。

后面在尝试编译的过程中发现提示没有gcc,所以我就安装gcc了（yum –y install gcc）。

======================================================================

以 Fedora 12 为例，通过图文方式讲解 Fedora 的安装过程和配置信息。

从《开始转向 Linux》一文中提供的 Fedora 12 的下载地址，下载好之后就可进行安装了。这套教程假设你没有任何 Linux 的技术背景，完全从头开始学习，所以我们首先在虚拟机中进行操作和学习。

如何使用虚拟机不在本文讨论范围，请自行查找相关资料。

作为这个教程中使用的系统，建议将 Fedora 的虚拟硬盘设置为 8G。有关 Fedora 分区的内容在以后的文章中在详细讨论。

准备好了虚拟机和 Fedora 12 的光盘镜像，下面就开始了……

将 Fedora 12 的镜像载入虚拟机，并设置从光盘启动，以下就是运行 Fedora 12 安装光盘的首个菜单。选择第一项 —— "Install or upgrade an existing system(安装新系统 或者 升级一个已存在的系统)"

然后会看到一大片如下的检测和准备信息，等待就好了……

准备完成，提示是否测试光盘。这一步的意思在正式安装前，检测 CD 或 DVD 是否有损坏。因为我们直接从官方下载的境像，所以可以选择 Skip (略过)。 —— 实际上，使用光盘安装也没什么好检测，如果盘坏了，检测出来是坏盘也没什么太大帮助 :D

之后就出现 Fedora 的安装向导，到这里就说明 Fedora 开始收集基本配置信息了。直接 Next

选择安装过程中的语言 —— English(English)。这个语言选择只对安装进程有效，我们使用 English，之后会讨论如何设置中文界面。

选择键盘类型 —— U.S.English，下一步

接下来设置计算机名称，大家为机器取一个好听有名字吧，或者直接就叫 Fedora :D，下一步

选择时区。使用上面的图形也可以，使用下面的下拉框也行，选择 Asia/Shanghai，下一步

设置 root 密码(也称“根密码”)。root 相当于 Windows 下的 Administrator，这个账户对整个系统有完全控制权。所以密码要设置得强悍一些 :D

PS:符合复杂的密码的要求为“长度大于6位，包含大写字母、小写字母、数字、符号四类中的三种”，如果密码不够复杂，系统会提示“密码强度不够，是否一定要使用”。

到这里，Fedora 12 的基本安装信息就收集好了，很简单吧。坏消息是，整个安装过程还没完；好消息是，接下来的内容也很简单 :D

图文讲解 Fedora 的安装过程，说明安装过程中的基本配置信息。

按照《安装 Fedora 12 (一) - 基本设置》和《安装 Fedora 12 (二) - 磁盘分区及软件包选择》安装好 Fedora 之后，重启计算机之后对 Fedora 进行最后的一些设置。

重启计算机之后，启动 Fedora 便会看到一个欢迎界面，左侧的菜单表示进度，告诉我们接下来还要做的事情有 —— 了解授权信息、创建用户、设置日期和时间、硬件信息。点击 Forword (前进)。

Fedora 授权信息，下一步

创建新用户 —— 因为 Root (根用户) 对整个系统有安装控制权限，从安全性方面考虑，要求创建普通用户。为了方便，暂时先将用户名和命名设置为 lugir，相关内容会在讲用户账户时提到。

填写好用户名、全名、密码、确认密码栏之后，下一步。

设置时间日期，然后下一步

显示硬件信息，保持默认 "Do not send profile (不发送配置)"，点击 Finish (完成)

系统提示 “是否真的不发送硬件配置”，选择 “No, do not send (不发送)”

之后便会显示登录界面，以后每次开机都会看到这个界面

选择你的用户名，输入密码，登录，就可以进入桌面了，有点激动人心吧，哈哈

到这里，Fedora 12 的安装就全部完成了，在进行下一节之前，可以四处点点，随便看看 :D

原文： http://lugir.com/install-fedora-3.html

前段时间部门内部PCM就SVN的代码管理和大家进行了分享，中途提到一个问题，就是和CVS相比，到底SVN有何优势，因为公司内部很早就开始用SVN了，所以很多同事都没有经历过CVS的时代；

偶在前一家公司的时候曾经用过CVS，就从开发人员的使用角度来说差别并不明显，我能想起来的也就是两三点：1、CVS对目录的管理非常不友好，无法跟踪目录的变动情况；2、文件无法重命名提交；3、对二进制文件（比如图片）的管理不好，代码合并时经常问题；

那具体两者间的差别有哪些呢？这几天从网上搜罗了一些，贴在这里供大家参考：

安装CVSNT-2.5.03

下载CVSNT，从网站http://www.march-hare.com/cvspro/上下载软件，

我下载的是cvsnt-2.5.03.2260.msi。

运行安装文件，

单击“Next >”

选择“I accept the terms in the License Agreement”核选项

单击“Next >”

选择安装模式，这里我选择的是“Complete”

单击“Install”

单击“Finish”

单击“Yes”重起电脑（注意保存未保存的资料）

====================重起========================

建立数据仓库

打开“开始”->“所有程序”->“CVSNT”->“CVSNT Control Panel”

选择“Repository configuration”页面

单击“Add”按钮

单击“Location”后面的“…”按钮选择建立仓库的位置

单击“OK”按钮，出现询问是否要初始化的对话框。

注意1：选择的路径对应的文件夹下不能有名为“CVSROOT”的文件夹，否则不会弹出下面的对话框。

注意2：如果服务器与客户端在同一电脑上，又在同一工作硬盘分区上的话，不要使硬盘分区上存在CVS目录，该目录被保留为客户端的临时目录。

单击“是(Y)”按钮初始化。

单击“确定”按钮退出程序。

测试服务器是否安装成功

开始菜单->run->cmd，进入命令行环境

输入“CVS”，会出现相应的帮助，如果没出现，说明环境变量中的Path值没有设置，你可以手动设置到文件所在的目录

输入：“set cvsroot=:sspi:localhost:/cvsdata”

（最后一个冒号后面的“/cvsdata”是前面设置的Repository名字）

输入“cvs version” ,显示当前CvsNt版本号

输入“cvs login”，并输入windows的登录密码

输入“cvs ls”，显示所有module，至少会有一个CVSROOT

添加用户（实验失败…）

1.使用cvs passwd命令可以添加用户和修改密码

2.可以修改 C:/cvsdata/cvsroot目录下的passwd文件，如果没有的话，可以自己建一个。添加 test:,这样就添加了一个密码为空的test用户了。