1. sudo xvidtune
2. 用left和right按钮调屏幕位置，再test按钮试一试满意没有，满意了，就下一步，不满意再用left和right按钮调整。
3. 按show，好让终端有类似 "1024x768" 94.50 1024 1093 1168 1376 768 769 772 808 +hsync +vsync 的出现。
4. sudo gedit /etc/X11/xorg.conf，先另存为，作一个备份。然后找到Section "Monitor"中当前分辨率的那段，你应该会看到类似 Modeline "1024x768" 94.50 1024 1093 1168 1376 768 769 772 808 +hsync +vsync这样的语句（没有的话就将记下来的东西在开头加Modeline，将它添加到EndSection的前面），按照刚才记下来的东西修改其中的相应位置的数值，改完后保存文件为原来的xorg.conf，注销，然后重起xwindow，搞定！
第一范式（1NF）：在关系模式R中的每一个具体关系r中，如果每个属性值 都是不可再分的最小数据单位，则称R是第一范式的关系。例：如职工号，姓名，电话号码组成一个表（一个人可能有一个办公室电话 和一个家里电话号码） 规范成为1NF有三种方法：
一是重复存储职工号和姓名。这样，关键字只能是电话号码。
二是职工号为关键字，电话号码分为单位电话和住宅电话两个属性
三是职工号为关键字，但强制每条记录只能有一个电话号码。
以上三个方法，第一种方法最不可取，按实际情况选取后两种情况。
第二范式（2NF）：如果关系模式R（U，F）中的所有非主属性都完全依赖于任意一个候选关键字，则称关系R 是属于第二范式的。
例：选课关系 SCI（SNO，CNO，GRADE，CREDIT）其中SNO为学号， CNO为课程号，GRADEGE 为成绩，CREDIT 为学分。 由以上条件，关键字为组合关键字（SNO，CNO）
在应用中使用以上关系模式有以下问题：
a.数据冗余，假设同一门课由40个学生选修，学分就 重复40次。
b.更新异常，若调整了某课程的学分，相应的元组CREDIT值都要更新，有可能会出现同一门课学分不同。
c.插入异常，如计划开新课，由于没人选修，没有学号关键字，只能等有人选修才能把课程和学分存入。
d.删除异常，若学生已经结业，从当前数据库删除选修记录。某些门课程新生尚未选修，则此门课程及学分记录无法保存。
原因：非关键字属性CREDIT仅函数依赖于CNO，也就是CREDIT部分依赖组合关键字（SNO，CNO）而不是完全依赖。
解决方法：分成两个关系模式 SC1（SNO，CNO，GRADE），C2（CNO，CREDIT）。新关系包括两个关系模式，它们之间通过SC1中的外关键字CNO相联系，需要时再进行自然联接，恢复了原来的关系
第三范式（3NF）：如果关系模式R（U，F）中的所有非主属性对任何候选关键字都不存在传递信赖，则称关系R是属于第三范式的。
例：如S1（SNO，SNAME，DNO，DNAME，LOCATION） 各属性分别代表学号，
姓名，所在系，系名称，系地址。
关键字SNO决定各个属性。由于是单个关键字，没有部分依赖的问题，肯定是2NF。但这关系肯定有大量的冗余，有关学生所在的几个属性DNO，DNAME，LOCATION将重复存储，插入，删除和修改时也将产生类似以上例的情况。
原因：关系中存在传递依赖造成的。即SNO -> DNO。 而DNO -> SNO却不存在，DNO -> LOCATION, 因此关键辽 SNO 对 LOCATION 函数决定是通过传递依赖 SNO -> LOCATION 实现的。也就是说，SNO不直接决定非主属性LOCATION。
解决目地：每个关系模式中不能留有传递依赖。
解决方法：分为两个关系 S（SNO，SNAME，DNO），D（DNO，DNAME，LOCATION）
注意：关系S中不能没有外关键字DNO。否则两个关系之间失去联系。
BCNF：如果关系模式R（U，F）的所有属性（包括主属性和非主属性）都不传递依赖于R的任何候选关键字，那么称关系R是属于BCNF的。或是关系模式R，如果每个决定因素都包含关键字（而不是被关键字所包含），则RCNF的关系模式。
例：配件管理关系模式 WPE（WNO，PNO，ENO，QNT）分别表仓库号，配件号，职工号，数量。有以下条件
a.一个仓库有多个职工。
b.一个职工仅在一个仓库工作。
c.每个仓库里一种型号的配件由专人负责，但一个人可以管理几种配件。
d.同一种型号的配件可以分放在几个仓库中。
分析：由以上得 PNO 不能确定QNT，由组合属性（WNO，PNO）来决定，存在函数依赖（WNO，PNO） -> ENO。由于每个仓库里的一种配件由专人负责，而一个人可以管理几种配件，所以有组合属性（WNO，PNO）才能确定负责人，有（WNO，PNO）-> ENO。因为 一个职工仅在一个仓库工作，有ENO -> WNO。由于每个仓库里的一种配件由专人负责，而一个职工仅在一个仓库工作，有 （ENO，PNO）-> QNT。
找一下候选关键字，因为（WNO，PNO） -> QNT，（WNO，PNO）-> ENO ，因此 （WNO，PNO）可以决定整个元组，是一个候选关键字。根据ENO->WNO，（ENO，PNO）->QNT，故（ENO，PNO）也能决定整个元组，为另一个候选关键字。属性ENO，WNO，PNO 均为主属性，只有一个非主属性QNT。它对任何一个候选关键字都是完全函数依赖的，并且是直接依赖，所以该关系模式是3NF。
分析一下主属性。因为ENO->WNO，主属性ENO是WNO的决定因素，但是它本身不是关键字，只是组合关键字的一部分。这就造成主属性WNO对另外一个候选关键字（ENO，PNO）的部 分依赖，因为（ENO，PNO）-> ENO但反过来不成立，而P->WNO，故（ENO，PNO）-> WNO 也是传递依赖。
虽然没有非主属性对候选关键辽的传递依赖，但存在主属性对候选关键字的传递依赖，同样也会带来麻烦。如一个新职工分配到仓库工作，但暂时处于实习阶段，没有独立负责对某些配件的管理任务。由于缺少关键字的一部分PNO而无法插入到该关系中去。又如某个人改成不管配件了去负责安全，则在删除配件的同时该职工也会被删除。
解决办法：分成管理EP（ENO，PNO，QNT），关键字是（ENO，PNO）工作EW（ENO，WNO）其关键字是ENO
缺点：分解后函数依赖的保持性较差。如此例中，由于分解,函数依赖（WNO，PNO）-> ENO 丢失了, 因而对原来的语义有所破坏。没有体现出每个仓库里一种部件由专人负责。有可能出现 一部件由两个人或两个以上的人来同时管理。因此，分解之后的关系模式降低了部分完整性约束。
一个关系分解成多个关系，要使得分解有意义，起码的要求是分解后不丢失原来的信息。这些信息不仅包括数据本身，而且包括由函数依赖所表示的数据之间的相互制约。进行分解的目标是达到更高一级的规范化程度，但是分解的同时必须考虑两个问题：无损联接性和保持函数依赖。有时往往不可能做到既有无损联接性，又完全保持函数依赖。需要根据需要进行权衡。
1NF直到BCNF的四种范式之间有如下关系：
BCNF包含了3NF包含2NF包含1NF
小结：
目地：规范化目的是使结构更合理，消除存储异常，使数据冗余尽量小，便于插入、删除和更新
原则：遵从概念单一化 "一事一地"原则，即一个关系模式描述一个实体或实体间的一种联系。规范的实质就是概念的单一化。
方法：将关系模式投影分解成两个或两个以上的关系模式。
要求：分解后的关系模式集合应当与原关系模式"等价"，即经过自然联接可以恢复原关系而不丢失信息，并保持属性间合理的联系。
注意：一个关系模式结这分解可以得到不同关系模式集合，也就是说分解方法不是唯一的。最小冗余的要求必须以分解后的数据库能够表达原来数据库所有信息为前提来实现。其根本目标是节省存储空间，避免数据不一致性，提高对关系的操作效率，同时满足应用需求。实际上，并不一定要求全部模式都达到BCNF不可。有时故意保留部分冗余可能更方便数据查询。尤其对于那些更新频度不高，查询频度极高的数据库系统更是如此。
在关系数据库中，除了函数依赖之外还有多值依赖，联接依赖的问题，从而提出了第四范式，第五范式等更高一级的规范化要求。在此，以后再谈。
各位朋友，你看过后有何感想，其实，任何一本数据库基础理论的书都会讲这些东西，考虑到很多网友是半途出家，来做数据库。特找一本书大抄特抄一把，各位有什么问题，也别问我了，自已去找一本关系数据库理论的书去看吧，说不定，对各位大有帮助。说是说以上是基础理论的东西，请大家想想，你在做数据库设计的时候有没有考虑过遵过以上几个范式呢，有没有在数据库设计做得不好之时，想一想，对比以上所讲，到底是违反了第几个范式呢？
我见过的数据库设计，很少有人做到很符合以上几个范式的，一般说来，第一范式大家都可以遵守，完全遵守第二第三范式的人很少了，遵守的人一定就是设计数据库的高手了，BCNF的范式出现机会较少，而且会破坏完整性，你可以在做设计之时不考虑它，当然在ORACLE中可通过触发器解决其缺点。以后我们共同做设计之时，也希望大家遵守以上几个范式。
花了一些时间去找了相关资料
终于找到了那个文件
/etc/fstab
这个文件真难找呀
关键词：Oracle数据库 分区Partition 表空间Tablespace 数据文件Datafile
伴随着信息高速公路的飞速建设，油田的各项勘探开发数据都做到了及时准确入库，数据库中数据量日益增加。以其下属的某个采油厂为例，数据量已达到2GB，各种数据库表更是多达1千多个。与此同时，又产生了一个新问题，那就是虽然各种生产数据都已入库，但是由于数据量巨大，造成查询速度非常缓慢。
本文以油井日度数据表（dba01）为例进行说明。该表是最基础的开发数据，每天每一口井都有记录进入到数据库中。油田规定，该数据15个月内必须保存在线，15个月下来这个表就有997890条记录。
这接近100万条的记录大大增加系统开销，在用户提交查询后，经常需要等待五六分钟才能得到结果，有时甚至查不出数据，给用户的感觉是仿佛处于“死机”状态。
1 常规解决办法
解决大表查询速度缓慢的问题，最初的对策是在后台创建很多中间表。
例如：要得到采油厂生产日数据汇总情况屯解全厂每天的油井开井数、水井开井数、日产油量、注采比等重要数据，其缺点主要有两个：
（1）中间表的建立会占用大量表空间，即查询速度的提高是以牺牲服务器空间为代价，造成了巨大的资源浪费；
（2）随着各种应用的不断开展，中间表的数量也越来越多，这样人为加大了数据管理和维护的工作量。
因此，要从根本上解决大表存在的查询速度缓慢的问题，必须找到更为有效的方法。
2 采用分区功能解决问题
（1）分区的定义
分区将表分离在若干不同的表空间上，将大的表和索引拆分成小的易于管理的数据片段，分而治之支撑无限膨胀的大表，给大表物理一级的可管理性。将大表分割成较小的分区可以改善表的维护、备份、恢复、事务及查询性能。针对我厂大量的油水井日度数据，可以推荐使用Oracle9的分区功能。
（2）分区的优点
首先，能够成倍提高查询速度：分区管理后，服务器可以进行智能的分区检测。跳过与查询无关的分区访问，并跳过不在线的分区。
其次，增强系统可用性：如果表的一个分区由于系统故障而不能使用，其余好的分区仍然可能使用。
不同分区可以跨表空间存储，降低了磁盘损坏带来的数据不可用性。
3 分区的管理
（1）建立表的各个分区的表空间
下面是建立2004年第一季度表空间的操作语句，指定所建立表空间的名字，所用数据文件的名称、大小和存放目录，并由存储字句指定在该空间中所建立对象的缺省存储参数。
CREATE TABLESPACE ts_dba01_2004q1
DATAFILE '/home2/oracle/test/dba01/2004q1.SIZE 200MB
DEFAULT STORAGE (INITIAL 30m NEXT 30m)
MINEXTENTS 3 PCTINCREASE 0);
(2)建立分区表
下面是建立dba01表的操作语句，指定表名、列名及列的数据类型等。这些都与常规创建表的语句相同。
CREATE TABLE dba01
(jh varchar2(16)not null,
rq date not null,
cyfs varchar2(3),
dwdm varchar2(11),
……
PARTITION BY RANGE(rq)
PARTITION dba01_2003q4
VALUES LESS THAN(TO_DATE('2004-01-01','YYYY-MM-DD')
TABLESDPACE ts_dba01_2003q4,
PARTITION dba01_2004q1
VALUES LESS THAN(TO_DATE('2004-04-01','YYYY-MM-DD')
TABLESPACE ts_dba01_2004q1)
这是创建分区的语句，指定指照日期进行分区，例如：
日期>='2004-01-01'并且<'2004-04-01'（即2004年第一季度）的数据放在dba01_2004q1分区内。其他分区也依此原则建立。
（3）分区表的扩充
在2004年年底，向表中加入2005年的表空间，同样是每季度一个表空间，预计每个分区为200MB。下面是创建2005年第一季度表空间的操作语句，指定表空间名称、数据文件名称及大小等。
CREATE TABLESPACE ts_dba01_2005q1
DATAFILE '/home2/oracle/dba01_2005q1.dat'SIZE
200MB
DEFAULT STORAGE (INITIAL 40m NEXT40m)
MINEXTENTS 3 PCTINCREASE 0）
其他季度表空间也如此建立。
（4）为表添加表空间
操作语句如下：
ALTER TABLE dba01
ADD PARTITION dba01_2005q1
VALUES LESS THAN(TO_DATE('2005-04-01','YYYY-MM-DD')
TABLESPACE ts_dba01_2005q1;
（5）删除不必要的分区
采油厂规定：必须保存15个月的日度数据在线。到2005年，必须把2003年3季度的数据备份，将该分区删除，腾出空间供后续数据循环使用。删除分区ALTER TABLE dba01 DROP PARTION dba01_2003q3;
利用操作系统工具删除这个分区所占用的文件
oracle$ rm /home2/oracle/test/dba01_2003q3.dat
（6）查看分区信息
可通过对数据字典USER_EXTENTS进行查询，操作如下：
SVRMGRL>SELECT *FROM user_extents
WHERE SEGMENT_NAME='dba01';
（7）卸载分区
Oracle9的EXPORT工具可卸载分区并导出数据，例如到2002年，可将2000年的数据按分区卸载。
例如：要卸载2003年3季度的数据，数据如下：
oracle$ exp tycx/***
tables=dba01:dba01_2003d3 file=dba01_2003q3.dmp
在语句中要指定用户名、口令、需要卸出的表名及分区名、卸出文件名称等。
（8）导入分区
Oracle9的IMPORT工具可导入分区并加载数据，例如在2005年，用户要查看2003年的数据，必须导入该年数据。
·建立该表2003年的四个表空间和相应的分区；
·下面是导入2003年3季度分区数据的操作语句：
oracle$ imp tycx/***
file=dba01_2003q3.dmp tables=(dba01:dba01_2003q3)
4 实验效果
（1）能够成倍提高查询速度
分区管理后，服务器可以进行智能的分区检测，跳过与查询无关的分区访问，跳过不在线的分区。
（2）增强系统可用性
如果表的一个分区由于系统故障而不能使用，其余好的分区仍然可以使用。
不同分区可以跨表空间存储，降低了磁盘损坏带来的数据不可用性。
以油井日数据表为例：
不采用分区技术时，若表空间文件受到破坏，会影响到所有数据都无法使用，必须将该表全部记录（多达100万条）重新恢复，工作量很大，恢复期间用户根本无法查询数据，完全不能使用。
而采用分区技术后，由于整个表已按季度拆分为6个分区，因此当某一个表空间文件被破坏，则仅是该分区表空间所对应的季度数据无法使用，其他季度数据仍然可以正常使用，对用户的查询以及其他应用影响不大。
通过合理应用Oracle9的分区功能，可以大大改善系统的性能，降低大表数据管理和维护的工作量，对大表的查询、增加、修改等操作可以分解到表的不同分区并行执行，可使运行速度更快。对促进无纸化办公，辅助生产有积极的推动作用。
翻译:廖斌
#//////////////////////////////////////////////////////////////////////
# 使用CVS进行版本管理
# 2000-6-30
# CVS 1.10.7
#
#
#
# Per Cederqvist et al 著
# 廖斌 译
# 感谢黄箐的输入和排版工作
# copyrigh： GPL
#
#//////////////////////////////////////////////////////////////////////
快捷内容索引
1． 概述.........................................................1
2． 代码仓库.....................................................7
3． 使用CVS开始一个项目..........................................29
4． 主干版本（Revision）.........................................33
5． 分支与合并...................................................41
6． Recarsive behavior...........................................49
7． 增加，删除，更名文件和目录...................................51
8． 回顾开发历史.................................................57
9． 放置二进制文件...............................................59
10 多个开发者的同时工作........................................61
11 主干版本管理.............................................71
12 关键字替代................................................73
13 跟踪第三方代码...............................................77
14 你的系统如何同CVS交互........................................81
15 特殊文件.....................................................83
16 附录
1） CVS命令导向..................................................85
2） CVS命令快速参考............................................115
3） 管理文件的参考习册.........................................127
4） 影响CVS的所有环境变量......................................141
5） CVS各版本之间的兼容性......................................143
6） 遇到的问题.................................................145
7） Credits....................................................153
8） 对CVS和这本手册的总是处理..................................155
目录 ...........................................................157
1 概论
这一章为从未用过CVS的人写的，也许以前也从未用过任何版本控制工具。
1.1 什么是CVS？
CVS是个版本控制系统，使用它你可以记录你原代码文件的历史。
例如，当软件修改时有时会产生问题（*bugs这里被译为问题），并且你可能在做这
次修改后很长时间不会发现这些问题。使用CVS，你可以容易地回顾老的代码版本去
发现哪一次的修改导致这些问题。有时候这样会非常有帮助。
你可能会保留你每一次的代码版本，这可能会浪费你很多的代码空间。CVS使用一
种聪明的办法保存你的多个版本在一个文件中。它仅仅保留版本间的不同内容。如果
你是一个项目中的一组成员之一，CVS也能够帮助你。除非你特别仔细，你很容易覆盖其
他人的工 作。一些编辑器，例如GNUEmacs，试图去判定一个文件是否被两人同时修改。
不幸的是，如果一个人使用其它的编辑器时，这个安全方式将不再有效。CVS使用让不同
开发者独立工作的方式解决了这个问题。每一个开发者的工作都在他自己的目录内，并且
CVS将 在每个开发者的工作完成后进行合并工作。
CVS是由Dick Grune作为Shell脚本的一个分支而创建的，1986年10月，在它的第6个发行卷
时，它被投递到新闻组comp.soures.unix。然而现在的CVS冲突算法中没有任何代码是从这
些脚本中来的。
在1989年3月，Brian Berlinor设计并编写了CVS的代码。Jett.Polk在以后帮助 Brian 完成了CVS
模型的设计和商业版本支持。
你可以通过不同的方式得到CVS，包括在Internet上自由的下载。如果你想下载CVS和其它CVS
文章以得到更多的信息，请看：
http：//www.cyxlic.com
http：//www.loria.fr/~molli/cvs-index.html.
有一个叫 info-cvs 的邮件列表是有关CVS的内容。订阅或取消订阅这个列表请发邮件到
info-cvs-request@gnu.org
如果你更喜欢Usenet新闻组，CVS的讨论组为
Comp.software.confg.mgmt.
在将来也许会建一个
Comp.software.confg.mgmt.cvs
的新闻组，
但也许这会是Comp.software.confg.mgmt在有太多讨论之后的事情吧。
你也许想订阅bug-cvs的邮件列表，这在附录H[BUGS]中有更多的信息。订阅它请发Email到
bug-cvs-reqnest@gnu.org.
1.2 CVS不能做的事
（未译）
2
3 使用CVS开始一个项目
=======================
因为更改文件名并且把它们移动到另一个目录中不是经常发生的，因此你在开始一个新项
目时要做的第一件事是考虑你的文件组织。更改文件名或移动文件并非不可能，但增加了
理解上潜在的费解，并且CVS在更改名字的目录上特别的敏感。请参见7.4节[移动文件]。
（* 译者注： 在Unix中改名和移动是相同的）。
下一步做的事取决于手中的情况。
3.1 建立文件
第一步是在仓库中建立文件。这可以使用多种不同的方法来完成。
--------------------------------------------------------------------
3.1.1 建立一个目录树
当你开始使用CVS时，你可能已经有几个项目可以使用CVS进行管理了。在这种情况下，
最容易的方法就是使用： ＂import＂命令。一个例子是最容易解释如何使用它的。假定你现
在有一些你想放到CVS中的文件在＂wdir＂中，并且你想让它们放在数据仓库中的如下目录：
＂$CVSROOT/yoyodyne/rdir＂
你可以使用如下命令：
$cd wdir
$cvs inport -m ＂Inported Sources＂ yoyodyne/rdir yoyo start
如果你没有使用＂-m＂参数记录一个日志信息，CVS将调用一个编辑器（*译者注：通常是vi）
并且提示输入信息。＂yoyo＂字符串是开发者标笺，＂start＂是发行标笺。他们没有什么特别
的意义，仅仅是因为CVS的需要才放在这里。
请参见第13章[跟踪代码]，得到更多的这方面信息。
你现在可以检查一下它是否有效了，然后可以删除你原来的代码目录。
$cd
$mv dir dir.orig
$cvs checkout yoyodyne/dir
$diff -r dir.orig yoyodyne/dir
$rm -r dir.orig.
为了避免偶然进入到你原来的目录中去编辑文件，删除原来的代码是个好主意。当然，在
你删除之前保留一份备份到其它地方也是明智之举。
＂checkout＂命令能使用模块名作为参数（正如前面所有例子）或是一个相对于$CVSROOT的路
径，如同上面的例子。你应当检查CVS目录中的权限情况是否合适，应当使它们属于某一个
特定的组。请参见2.2.2.节[文件权限]。
如果你想＂import＂的一些文件是二进制代码，你可以使用一些特殊的方法表明这些文件是否
是二进制文件。请参见C.2节[Wrappers]。
------------------------------------------------------------------------------------
3.1.2 从其它版本控制系统建立文件
如果你有一个其它版本控制系统维护的项目，例如RCS，你也许希望把这些文件放到CVS中，
并且要保留这些文件的历史。以下是一些讨论。
从RCS：
如果你使用RCS，找到RCS文件??通常一个文件名叫＂foo.c＂的文件会有＂RCS/foo.c,v＂的RCS文
件。（但它有可能在其它地方，请看RCS的文档以得到相关信息）。如果文件目录在CVS中不存
在，那在CVS中创建它。然后把这些文件拷贝到CVS的仓库目录中（在仓库中的名字必须是带
＂,v＂的原文件；这些文件直接放在CVS中的这个目录下，而非＂RCS＂子目录中）。这是在CVS中
一个为数不多的直接进入CVS仓库直接操作的情况，而没使用CVS命令。然后你就可以把它们
在新的目录下＂checkout＂了。
当你把RCS文件移动CVS中时，RCS文件应在未被锁定的状态，否则移动操作时CVS 将会出
现一些问题。
从其它版本控制工具
许多版本控制工具都可以输出＂RCS＂格式的标准文档。如果你的版本控制工具可以做到这一
点，直接输出RCS文件，然后按照上面的例子做就可以了。
如果你的版本工具不能输出RCS文件，那么你必需要写一个脚本文件来，每次取出一个版本
然后把它放到CVS中去。下面提到的＂sccsarcs＂脚本就是一个很好的例子。
从SCCS：
有一个＂sccsarcs＂的脚本文件可以做把SCCS的文件转化成RCS文件，这个文件放在CVS原代码
目录的＂contrib＂目录中。注意：
你必须在一台同时安装了RCS和SCCS的机器上运行它。并且，正如其它在＂contrib.＂目录中的
其它脚本一样。（你的方法也许是变化多端的）
（*译者注：我并未查看过CVS的contrib目录：-（，因此不知道这下面都有些什么）。
从PVCS：
在＂contrb＂中有一个叫＂pves-to-rcs＂的脚本可以转换PVCS到RCS文件。你必须在一台同时有
PVCS和RCS的机器上运行它。
请看脚本中的注释以得到更多细节。
3.1.3从无到有建立一个目录树
建立一个新的项目，最容易的方法是建立一个空的目录树，如下所示：
$mkdir tc
$mkdir tc/man
$mkdir tc/testing
在这之后，你可以＂import＂这个（空）目录到仓库中去。
$cd tc
$cvs import -m ＂created directory structure＂yoyodyne/dir yoyo
start
然后，当新增一个文件时，增加文件（或目录）到仓库中。请检查$CVSROOT中的权限是否正确。
-------------------------------------------------------------------------------------------
3.2 定义模块
下一步是在＂moduyes＂文件中定义模块。这不是严格需要的，但模块能把相关的目录和文件容易
关联起来。下面的例子可以充分演示如何定义模块。
1. 得到模块文件的工作拷贝。
$cvs checkout CVSROOT/modules
$cd CVSROOT
2.
编辑这个文件并写入定义模块的行。请参见2.4节[管理文件的介绍]。有一个简单介绍，参见C.1节
[模块文件]。有它的详细描述。你可以使用下面的行定义模块＂tc＂：
tc yoyodyne/tc
3. 提交你的更改到仓库
$cvs commit -m ＂Added tc module.＂ modules
4. 发行模块文件
$cd
$cvs release -d CVSROOT
4
=======
5 分支与合并
==================
CVS允许你独立出一个派生的代码到一个分离的开发版本---分支。当你改变一个分支中的文
件时，这些更改不会出现在主开发版本和其它分支版本中。
在这之后你可以使用合并（merging）把这些变更从一个分支移动到另一个分支（或主开发版
本）。合并涉及到使用“cvs update -j”命令，合并这些变更到一个工作目录。你可以确认
（commit）这次版本，并且因此影响到拷贝这些变更到其它的分支。
-----------------------------------------------------------------------------------
5.1 何时应当创建一个分支
假定tc.c发行版已完成。你正在继续开发tc.c，计划在2个月后发行1.1的版本。在不久以后你的
客户开始抱怨说代码有些问题，你检查了一下1.0的发行版（请参见4.4节[标笺]）并且找到了这
个错误（这将会有一个小小的更正）。但是，这个当前的版本是处于一个不稳的状态，并且在下
一个月才能有希望稳定下来。这样就没有办法去发行一个最新的现有版本去更正问题。
这时就可以去创建基于这棵版本树1.0版的分支。你可以修改这棵树的分支而不影响到主干。当
修订完成时，你可以选定是否要把它同主干合并或继续保留在这个分支里。
-----------------------------------------------------------------------------------
5.2 建立一个分支
你可以使用“tag -b”去建立一个分支。例如，假定你在工作于一个工作拷贝中：
$cvs tag -b rel_1_0_patches
这将基于当前的拷贝分离出一个分支，并分配“rel_1_0_patches”的名字。
懂得分支是在CVS仓库中创建，而非在工作拷贝中创建的是非常重要的。正上面的例
子，创建一个基于当前版本的分支不会自动把当前的工作拷贝转到新的分支上。欲知
详情，请看5.3节[进入 一个分支]。你也可以不参考任何工作拷贝而建立一个分支。
你可以使用rtag命令：
cvs rtag -b -r rel-1-0 rel-1-0-patches tc.
“-r rel-1-0”说明这个分支是基于标志了rel-1-0的版本文件，它不是从最新的版本
开始分支．这对需要从老的版本进行分支很有用（例如：当修订一个过去的稳定版本时）
当使用“tag”标志，这个“-b”标志告诉rtag去创建一个分支（而非是这个版本的符号
连接）。注意标记“rel-1-0”可能对不同的文件有不同的版本数字。因此，这个命令的结果
是为tc模块建立了一个命名为“rel-1-0-patches”的新版本分支，它是基于标记为“rel-1-0”
的版本树。
-----------------------------------------------------------------------------------
5.3 进入分支
你可以通过两种方式进入分支：重新checkout或是从现存的拷贝进入。重新checkout使用
checkout命令并带上“-r”标识，后面是这个分支的标笺（tag）名。（请看5.2［创建一个分支］）：
$cvs checkout -r rel-1-0-patches tc.
或者如果你已有了一个拷贝，你可以使用“update -r”命令转到这个分支。
$cvs update -r rel-1-0-patches tc.
或者使用另一个等同的命令：
$cd tc
$cvs update -r rel-1-0-patches
这对现有拷贝为主干代码或是其它分支都是有效的．上面的命令将把它转到命
名的分支。同“update”命令相类似。“update -r”合并你所做的任何改变，请注
意是否有冲突出现。
一但你的工作拷贝已经转向一个特定的分支。它将一直保持在这个分支内，除非你
又做了其它的操作。这意味着从这个工作拷贝checkin的变更将加到这个分支的新版
本中，而不影响到主干版本和其它分支代码。
想看一个工作拷贝是基于哪一个分支，可以使用“status”命令。在它们输出中查找
一个“sticky tag”的域（请参见4.9节[＂sticky tag＂]，第38页）．那就是你的当前分支号。
$cvs status -v driver.c backend.c
====================================================================
File： driver.c Status： Up-to-date
Version： 1.7 Sat Dec S 18：25：54 1992
RCS version： 1.7 /u/cvsroot/yoyodyne/tc/driver.c，v
Sticky Tag： rel-1-0-patches （branch： 1.7.2）
Sticky Date： （none）
Stick Option： （none）
Existing Tag：
rel-1-0-patches （branck： 1.7.2）
rel-1-0 （revision： 1.7）
====================================================================
File： backend.c status： Up-to-date
Version： 1.4 Tue Dec 1 14：39：01
Rcs Version： 1.4 /u/cvsroot/yoyodyne/tc/
Sticky Tag： rel-1-0patches（branch：1.4.2）
Sticky Date： （none）
Sticky Option： （none）
Existing Tag：
Rel-1-0-patches （branch： 1.4.2）
Rel-1-0 （revision： 1.4）
Rel-0-4 （revision： 1.4）
请不要因为每个文件的分支是不同（“1.7.2”和1.4.2＂）而迷惑。分支的标笺（tag）
是相同的：＂rel-1-0-patches＂，这些相同标笺的文件是相同分支的。在以上的例子中，分支建
立之前，＂driver.c＂ 比 ＂backend.c＂有更多的变更，因此它们的版本编号是不同的。请参见5.4节
[分支和主干版本号]去了解分支如何构建原理的细节。
--------------------------------------------------------------------------------------
5.4 分支与主干版本
通常，一个文件的主干版本历史是一个增长线（请看4.1[主干版本]页）：
+-----+ +-----+ +-----+ +-----+ +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !
+-----+ +-----+ +-----+ +-----+ +-----+
然而，CVS并不局限于线性的开发。主干版本可以分为不同的分支，每一个分支可
以是一个独立的自我维护的开发线。而在一个分支中的变更可以很容易的转移到主干中。
每一个分支均有一个分支号，由一个“.”分离的十进制奇数组成，分支号的编排依
赖于它分离出的主线版本。使用分支号允许从一个特定版本分离出多个分支。
所有的分支版本都依赖于它的原始分离版本号。下面的例子将展示这一点。
+-------------+
1.2.2.3.2 分支 -> +--! 1.2.2.3.2.1 !
! +-------------+
!
+---------+ +---------+ +---------+
1.2.2 分支-> +--! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.2 !
! +---------+ +---------+ +---------+
!
!
+-----+ +-----+ +-----+ +-----+ +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- 主干
+-----+ +-----+ +-----+ +-----+ +-----+
!
!
! +---------+ +---------+ +---------+
1.2.4 分支-> +--! 1.2.4.1 !----! 1.2.4.2 !----! 1.2.4.2 !
+---------+ +---------+ +---------+
你是如何创建具体的分支号的细节通常不是你需要考虑的，但这里谈谈它如何工作。
当CVS建立一个分支号时，它先得到第一个未用的偶数，开始的数字是2，例如你
从6.4的主干版本创建分支时，分支号为6.4.2所有分支号码末位为0的号码用于CVS内
部，（例如6.4.0）。（请参见5.5节[内部分支号]44页）分支1.1.1有特别的含义，请看13章
[跟踪代码]。
-----------------------------------------------------------------------------------
5.5 内部分支号码
这一节描述CVS的内部分支（magic branches） （* 译者注：magic branch 译为内部分支）
特性。在大多数情况下，你不用考虑内部分支号码，CVS将为你进行管理。然而，在
一些特定条件下，它将显现出来，因此理解它如何工作将是有用的。一般的，分支号
码将由奇数个 ＂.＂分隔的十进制整数组成。请看4.1节[版本号码]。然而那并非完全是这
样的，由于效率的原因，CVS有时插入一个额外的“0”在右末的第二个位置（1.2.4
变为1.2.0.4，8.9.10.11.12变为8.9.10.11.0.12等）。
CVS将会很好的将这些变换隐蔽在背后进行，但在一些地方，这种隐蔽并不完全：
* 内部分支编号会出现在CVS的日志（log）文件中。
* 你不能够对 ＂cvs admin＂ 使用符号分支名。
你可以使用admin命令去为一个分支重新分配一个RCS希望的那样的符号名。如果
R4patches是一个分配给分支1.4.2（内部分支编号为1.4.0.2）的一个文件＂numbers.c＂的
命名，你可以使用如下命令：
$cvs admin -NR4patches：1.4.2 numbers.c
它将只在至少一个版本已经提交到这个分支时才会有效。请非常小心不要把一个标
笺（tag）分配给了一个错误标识号（现在没有看到昨天的一个标笺是如何分配的）。
----------------------------------------------------------------------------------
5.6 合并一个整个分支
你可以合并一个分支到你的工作目录在“update”命令中“-j 分支号”的标识。使
用“-j 分支号”将合并这个派生分支点与原版本的最新版之间的变更到你的工作目录
“-j”的意思是“join”。
我们现在来考察下面这棵树：
+-----+ +-----+ +-----+ +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 ! <- 主干
+-----+ +-----+ +-----+ +-----+
!
!
! +---------+ +---------+
R1fix 分支-> +--! 1.2.2.1 !----! 1.2.2.2 !
+---------+ +---------+
分支1.2.2分配了一个Rifix的名字.下面的例子假定模块＂mod＂只包含一个文件＂m.c＂
$cvs checkout mod # 得到最新的1.4版
$cvs update -j R1fix m.c # 合并所有在分支中的改变，即：1.2与1.2.2.2
# 之间的变化到这个文件的工作目
录.
$cvs commit -m ＂Included R1fix # 建立1.5版
在合并时可能会发生冲突，如果这种情况发生，你可以在提交新版本之前解决它。请
参见10.3节[冲突的例子]。
如果你的原文件中包含关键字（请看第12章[关键字替代]）。你可能会得到比严格意义
上的冲突更多的冲突信息。请参见5.10节[合并和关键字]，去了解如何避免这个问题。
＂checkout＂命令也支持使用＂-j＂参数。下面的例子同上面所用的例子有相的效果。
$cvs checkout -j R1fix mod.
$cvs commit -m ＂Included R1fix＂
---------------------------------------------------------------------------------
5.7 从一个分支多次合并。
继续我们上面的例子。现在这棵树看起来是这样的：
+-----+ +-----+ +-----+ +-----+ +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- 主干
+-----+ +-----+ +-----+ +-----+ +-----+
! *
! *
! +---------+ +---------+
R1fix 分支-> +--! 1.2.2.1 !----! 1.2.2.2 !
+---------+ +---------+
正如上面所讨论的，分支1.2.2.2所引导的“*”号表示从Rifix分支到主干的合并。
现在我们继续开发Rifix分支：
+-----+ +-----+ +-----+ +-----+ +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- 主干
+-----+ +-----+ +-----+ +-----+ +-----+
! *
! *
! +---------+ +---------+ +---------+
R1fix 分支-> +--! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
+---------+ +---------+ +---------+
然后你可能会希望合并新的变更到主干中去。如果你仍使用“cvs update -j Fifix m.c＂
cvs将试图合并你已经合并过的东西，这可能写导致一些不希望发生的东西。
因此，你必须表达清楚你希望只合并未被合并的内容的意思。这样需要使用两个
“-j“参数。CVS合并从第一个“-j”的版本到第二个“-j”版本的变化。例如，在我们上面
的例子中：
cvs update -j 1.2.2.2 -j R1fix m.c
如果出现的问题是你需要手工指定1.2.2.2的版本号，一个更好的方法是使用：
cvs update -j R1fix：yesterday -j R1fix m.c
然而，更好的方式是在每一次合并后重新放一个标笺给Rifix分支，然后使用标
笺做后的合并：
cvs update -j merged_from_Rifix_to_trunk -j R1fix m.c
----------------------------------------------------------------------------------
5.8 合并两个任意版本之间的不同
使用两个“-j”标志，这个update（和checkout）命令能合并两个任意不同的版本
到你的工作目录。
$cvs update -j 1.3 backend.c
将把1.5版本恢复到1.3版本，所以一定要注意版本的顺序。
如果你在操作多个文件时使用这个选择项，你必须了解在不同的文件之间，版本的
数字可能是完全不同的。你必须使用标笺（tag）而不是使用版本号来完成多个文件
的操作。使用两个“-j”操作也能会恢复增加或删除的文件。例如，假定你有一个
叫“file1”的文件在在于1.1版本中，然后你在1.2版本中删除了它，下面是如何操作的例子：
$cvs update -j 1.2 -j 1.1 file1
file1
$cvs commit -m test
checking in file1;
/tmp/cvs-sanity/cvsroot/first-dir/file1 file1，v
new revision：1.3; previous revision：1.2 done
$
------------------------------------------------------------------------------------
5.9 合并能添加和删除文件
如果你在合并时的改变涉及到添加或删除一些文件，“update -j”将反映这些变化。
例如：
cvs update -A
touch a b c
cvs add a b c ; cvs ci -m ＂added＂ a b c
cvs tag -b branchtag
cvs update -r branchtag
touch d ; cvs add d
rm a ; cvs rm a
cvs ci -m ＂added d ， removed a＂
cvs update -A
cvs update -j branchtag
在这些命令之后（注意要commit），文件a将被删除，而文件d将被加入到主干。
-------------------------------------------------------------------------------------
5.10 合并和关键词
如果你合并的文件包含关键词（参见第12章[关键词替代]，73页），你通常将会在
合并时得到 无数个冲突报告，因为在不同版本中非常不同。
因此，你常需要在合并时使用“-kk”（参见12.4节[替代模式]，75页）选择项。使用
关键字名字，而非去扩展关键字的值的方法，这个功能选择项确保你合并的版本之间互相相
同，而避免了冲突。
例如：假设你有一个文件如下：
+---------+
br1 -> +--! 1.1.2.1 !
! +---------+
!
!
+-----+ +-----+
! 1.1 !----! 1.2 !
+-----+ +-----+
并且你的当前工作目录拷贝为主干（1.2版本）。那么对于以下的合并将会产生一个
冲突的结果。请看例子：
$cat file1
Key $Revision： 1.3 $
...
$cvs update -j br1
U file1
RCS file： /cvsroot/first-dir/file1，v
retrieving revision 1.1
retrieving revision 1.1.2.1
Meging differences between 1.1 and 1.1.2.1 into file1
rscmerge： warning： conflicts during merge
$ cat file1
$<<<<<<< file1
Key $Revision： 1.3 $
=======
Key $Rerision： 1.1.2.1 $
$>>>>>>> 1.1.2.1
...
冲突发生在试图将1.1和1.1.2.1合并到你的工作目录中去的时候。因此，当这个
关键词从“Revision：1.1＂到＂Revision：1.1.2.1＂时，CVS将试图合并这个变化到
你工作目录， 这就同你的目录中的变更“Revision：1.2＂发生了冲突。
以下是使用了：“-kk”后的例子：
$cat file1
key $Revision： 1.3 $
...
$cvs update -kk -j br1
V file1
RCS file： /cvsroot/first-dir/file1，v
retrieving revision 1.1
retrieving revision 1.1.2.1
Merging differences between 1.1 and 1.1.2.1 into file1
$ cat file1
key $Revision： 1.3 $
...
在这里版本“1.1”和“1.1.2.1＂都扩展为单纯的 ＂Revision＂，因此，合并时就不会
发生冲突了。
然而，使用 ＂-kk＂ 参数还一个主要的问题。即，它使用了CVS通常使用的关
键字扩展模式。在特殊情况下，如果模式使用针对二进制文件的 ＂-kb＂
参数。这将会产生问题。因此，如果你的数据库中包括有二进制文件，你将
必须手工处理这些问题，而不能使用 ＂-kk＂。
10 多个开发者同时工作
---------------------
当多个开发者同时参与一个项目时，常常会发生冲突。一般经常发生的情况是两个人想
同时编辑一个文件的时候。它的解决方法之一是文件锁定或是使用保留式的checkout，这种
方法允许一个文件一次只允许一个人编辑。这是一些版本控制系统的唯一解决方式，包括
RCS和SCCS。现在在CVS通常使用保留式checkout的方法是使用＂CVS admin-1＂命令（参见A-6-1AB
[admin选择项]）。在下面将解释这不是一种好的智能的解决方式，当它是许多人喜欢使用的
一种方式。下面也将讲述可以使用适当的方法来避免两个人同时编辑一个文件，而非使用软件
的方式强迫达到这一点。
在CVS中默认的方法是＂unreserved checkout＂--非保留式的导出。在这种方法下，开发者
可以同时在他们的工作拷贝中编辑一个文件。第一个提交工作的没有一种自动的方法可以知道
另一个人在编辑文件。另一个人可能会在试图提交时得到一个错误信息。他们必须使用CVS命令
使他们的工作拷贝同仓库的内容保持更新。这个操作是自动的。
CVS可以支持facilitate多种不同的通信机制，而不会强迫去遵守某种规则，如＂resered
checkouts＂那样。以下的部分描述这些不同的方式是如何工作的，和选择多种方式之间涉及到
的一些问题。
10．1 文件状态
基于你对导出的文件使用过的操作，和这些文件在仓库中的版本使用过的操作，我们可以
把一个文件分为几个状态。这个状态可以由＂status＂命令得到，它们是：
up-to-date：
对于正在使用的这个分支，文件同仓库中的最后版本保持一致。
Locally Modified：
你修改过文件，但没有＂commit＂。
Locally added：
使用了＂add＂命令增加文件，但没有＂commit＂
Locally Removed：
你使用了＂remove＂命令，但没有＂commit＂
Needs checkout：
其他人提交了一个更新的版本。这个状态的名字有些误导，你应当使用＂update＂而非
＂checkout＂来更新新的版本。
Needs Patch：
象＂Needs checkout＂一样，但CVS服务将只给出Patch（补丁）文件，而非整个文件。而
给出Patch和给出整个文件的效果是相同的。
Needs Merge：
一些人提交了一个更新版本，而你却修改过这些文件。
File had conflicts on merge：
这同＂Locally Modified＂相象，只是＂update＂命令给出了一个冲突信息。如果你还没有
解决冲突，那么你需要解这个问题，解决冲突的方法参见10.3节[冲突的例子].
Unkown：
CVS不知道关于这个文件的情况.例如，你创建了一个新文件，而没有使用＂add＂命令
为了帮助弄清楚文件的状态，＂status＂也报告工作版本（working
vevision），这是这个文件是从哪个版本来的，另外还报告＂仓库版本＂（Repository
vevision）。这是这个文件在仓库中的这个版本分支的最后版本。
＂status＂命令的选择项例在附录B[invoking cvs]。有关＂sticky tag＂和＂sticky
date＂输出内容的信息，参见4.9节[sticky tags]。有关＂sticky options＂输出内容参见＂-k＂选择项，
A.16.1节[update选择项]。
你应当把＂update＂和＂status＂命令放在一起来认识。你使用＂update＂使你的文件更新到最
新状态，你使用＂status＂命令来得到＂update＂命令将会做何种操作。（当然，仓库中的状态将可
能会在你运行update之前变化）。事实上，如果你想使用一个命令得到比使用＂status＂正式的状
态信息，你可以使用：
$cvs -n -q -update
这里＂-n＂选择项表示不真正执行update，而只显示状态；＂-q＂选择项表示不打印每个目录的
名字。有关更多的关于＂update＂命令的住处参见附录B[使用CVS]。
10．2 使一个文件更新到最版本
当你想更新或是合并一个，使用update命令。对于一个不是最新版本的文件，这个命令大略等
同于＂checkout＂命令：最新版本从仓库中提出并放到工作目录中。
当你使用＂update＂命令时，你修改过的文件在任何情况下不会受到损害。如果在仓库中没有更
新的版本，＂update＂时你的代码没有任何影响。当你编辑过一个文件，并且仓库中有更新版本，那
么＂update＂将合并所有的变更到你的工作目录。
例如，想象一个你导出了一个1.4版的文件并且开始编辑它，在某一时候其他人提交了1.5版，然
后又提交了1.6版，如果你运行update命令，CVS将把1.4版到1.6版之间的变更放到你的文件中。
如果在1.4版和1.6版之间的改变太靠近于的你一些变更的话，那么一个＂覆盖＂（＂overlop＂）冲突
就发生了。在这种情况下将输出一个警告信息，然后结果保留的文件中包含了有冲突代码的两个版
本，由特别的符号所分隔开。请参见A.16节[更新]，可以得到关于＂update＂命令的一个完全的描述。
来源：中国Linux论坛
