C1G军火库

下午参照lukew的ui做了个table

本来想实现类似phpmyadmin的显示样式，可以当前行高亮并可以做标记，不过没找到很好的实现方法。
hover目前支持ie7和firefox

点击查看table ui

使用通过文件名index.php、INDEX.php来区分，windows是不区分大小写的。

来自http://man.chinaunix.net/develop/cvsdoc_zh/

这是关键字列表：

$Author$
检入该版本的用户登录名。

$CVSHeader$
标准的头部(类似去掉 CVS 根的 $Header$)。包括 rcs 文件的全路径、版本号、日期（UTC）、作者、状态、加锁人（如果有锁）。在使用 cvs 中文件通常不用加锁。
注意，该关键字是新加到 cvs 的，假如旧的文件中有 $CVSHeader$ 并有其他意义，会带来一些问题。可以在 CVSROOT/config 中用 KeywordExpand=eCVSHeader 来排除此关键字。参阅 Configuring keyword expansion。

$Date$
该版本被检入的日期与时间（UTC）。

$Header$
标准的 header 包括 rcs 文件的全路径、版本号、日期（UTC）、作者、状态、加锁人（如果有锁）。 在使用 cvs 中文件通常不用加锁。

$Id$
除了 rcs 文件不包括路径，其余和 $Header$ 相同。

$Name$
检出此文件所用的标签名。该关键字只在检出时显式加上标签时扩展。比如，运行 cvs co -r first 命令时，关键字扩展为 `Name: first’。

$Locker$
锁定版本的用户登录名（如果没有加锁此项为空，一般就如此，除非使用 cvs admin -l 加锁）。

$Log$
日志信息在提交时提供，前面是一个 header 包括 rcs 文件名、版本号、作者、日期（UTC）。已有的日志信息不会被替换。相反，新日志信息将插在 $Log:…$之后。默认，每一新行前面使用同样的 $Log$ 关键字前的字符串, 除非在 CVSROOT/config 里面设置 MaxCommentLeaderLength。
例如，文件文件包含：

/* Here is what people have been up to:
*
* $Log: frob.c,v $
* Revision 1.1 1997/01/03 14:23:51 joe
* Add the superfrobnicate option
*
*/

新增的行扩展 $Log$ 关键字后前面也会带有 ` * ‘ 字符。与以前版本的 cvs 和 rcs不同，rcs 文件中的不再使用 comment leader。 $Log$ 关键字将会在源文件中累积日志纪录。有些原因可能会造成问题。

如果 $Log$ 关键字的前缀超出 MaxCommentLeaderLength 长度， CVS 将跳过关键字扩展，除非在 CVSROOT/config 中设置 UseArchiveCommentLeader，并且有 `comment leader’ 设置在 RCS archive 文件，使得 comment leader 替代使用。为了了解更多关于 RCS archive 中设置 comment leader，参阅 admin. 了解更多默认的 $Log$ 替换配置，参阅 config.

参阅 Log keyword.

$RCSfile$
不带路径的 RCS 文件名。

$Revision$
该文件的修订版本号。

$Source$
RCS 文件的完整路径。

$State$
赋予版本的状态。可以通过使用 cvs admin -s 命令设置状态—参阅 admin options。

Local keyword
CVSROOT/config 文件中的 LocalKeyword 选项可以被用作其他关键字的别名: $Id$, $Header$, or $CVSHeader$。例如，在 CVSROOT/config 中包含 LocalKeyword=MYBSD=CVSHeader 这样一行，带有 $MYBSD$ 的文件会像 $CVSHeader$ 一样被扩展。如果 src/frob.c 文件包含这个关键字，像下面这样：
/*
* $MYBSD: src/frob.c,v 1.1 2003/05/04 09:27:45 john Exp $
*/

许多仓库使用 “local keyword” 这类特性。 cvs 的一个旧补丁提供 LocalKeyword 特性，它们使用称为“custom tag”或“local tag”特性的 tag= 选项。它被用于它们称为 tagexpand= 选项。在 cvs 中另一个选项为 KeywordExpand。参阅 Configuring keyword expansion。

知名的项目中有这些例子： $FreeBSD$, $NetBSD$, $OpenBSD$, $XFree86$, $Xorg$.

使用它的优点在于可以使用自己的版本信息而不破坏上面版本(它们可能使用不同的 local keyword 或标准关键字)。使得 bug 报告可以更恰当地识别第三方的错误源，以及减少导入新版本时产生的冲突数。

除 local keyword 之外所有的关键字都可以在 CVSROOT/config 文件中用 KeywordExpand 选项停用—参阅 Configuring keyword expansion 获得详细信息。

一般而言，DOM结构准确地反映了HTML文档所包含的内容，也就是说，每个HTML标记表现为一个标记节点（tag node），每个文本项内容表现为一个文本项节点（text node）。这种表现形式一般称为WYSIWYG，即所见即所得。但是，

标记是一个例外情况。当有标记时，我们可以设想它另外包含一对标记。来看看下面的一段代码：

　　
　　
　　
　　

This is row 1, cell 1	This is row 1, cell 2
This is row 2, cell 1	This is row 2, cell 2
This is row 3, cell 1	This is row 3, cell 2

　　在分析它的DOM结构前，我们要为这段代码添加上一对标记：

　　

　　
　　　　　　　　中间代码略
　　
　　

　
pointer：ff和ie下通用的手型。
hand：是大家所熟悉的手型。< br>
　　crosshair：是十字型，就是小乌龟首页所用的样式。< br>
　　text：是平时鼠标移动到文本上的样式。< br>
　　wait：是等待的效果。< /span>
　　default：是默认的那种效果。 < br>
　　help：是带问号的鼠标样式。< br>
　　e-resize：是向右的箭头。< br>
　　ne-resize：是向右上方的箭头。< br>
　　n-resize：是向上的箭头。< br>
　　nw-resize：是向左上方的箭头。< br>
　　w-resize：是向左的箭关。< br>
　　sw-resize：是向左下的箭头。< br>
　　s-resize：是向下的箭头。< br>
　　se-resize：是向右下方的箭头。< br>
　　auto：是系统自动的效果。

在CVS里有一个很有用的功能，就是将源文件中的一些关键字替换，例如提交时间，作者等。Subversion默认不会对此类关键字进行处理，需要设置一些属性，才能实现。

例如我们要在某个源文件的头上自动添加最后一个修改人的名字和提交的时间，首先我们为这个文件设置属性svn:keywords的值为“Date Author”，然后在这个文件需要添加作者和提交时间的地方增加下面这样的字段：

$LastChangedDate$
$Author$

这样这个文件提交后，对应的字符变成了下面的样子：

$LastChangedDate: 2006-11-29 22:58:16 +0800 (星期三, 29 十一月 2006) $
$Author: root $

这里还存在一个问题，就是Subversion总是使用UTF-8替换文本，文件必须使用UTF-8编码。如果我们的文件编码是GBK，而日期显示格式是上面的汉字形式，或者文件路径、文件名包含中文那得到的将是乱码的。
所以最好还是避免使用$Date$ 和 $HeadURL$。

Subversion定义了用来替换的关键字列表，这个列表保存了如下五个关键字，有一些也包括了可用的别名：

Date
这个关键字保存了文件最后一次在版本库修改的日期，看起来类似于$Date: 2002-07-22 21:42:37 -0700 (Mon, 22 Jul 2002) $，它也可以用LastChangedDate来指定。

Revision
这个关键字描述了这个文件最后一次修改的修订版本，看起来像$Revision: 144 $，也可以通过LastChangedRevision或者Rev引用。

Author
这个关键字描述了最后一个修改这个文件的用户，看起来类似$Author: harry $，也可以用LastChangedBy来指定。

HeadURL
这个关键字描述了这个文件在版本库最新的版本的完全URL，看起来类似$HeadURL: http://svn.collab.net/repos/trunk/README $，可以缩写为URL。

Id
这个关键字是其他关键字一个压缩组合，它看起来就像$Id: calc.c 148 2002-07-28 21:30:43Z sally $，可以解释为文件calc.c上一次修改的修订版本号是148，时间是2002年7月28日，作者是sally。

具体如何做呢?

首先在代码文件里写上相关属性

在windows下安装TortoiseSVN后
你可以在一个受控文件上右键－＞属性，然后到Subversion属性页
设置svn:keywords，根据你的需要选择Id,Url,Author,Date,Rev

设置后，提交这个文件，再打开就可以看到效果

但是这样单个文件操作太麻烦了，我们可以让svn自动帮我们处理。
右键->svn->seeting->general->Subversion configuation file: edit

去掉enable-auto-props 前的#

下增加
*.php = svn:eol-style=native;svn:keywords=Id Author Revision
这样对php文件就会自动处理Id Author Revision三个属性。

因为svn的属性保存在本地，所以开启后只对以后add或commit的文件有启,如果以后新增属性如:HeadURL,是无效果的。
同样以后关闭auto-props 对以前的文件也是没有影响的。

http://www.ibm.com/developerworks/cn/linux/filesystem/l-fs/index.html

ReiserFS 技术

那么 ReiserFS 是怎样提供如此出色的小文件性能的呢？ReiserFS 使用了特殊的优化 b* 平衡树（每个文件系统一个）来组织所有的文件系统数据。这为其自身提供了非常不错的性能改进，也能够减轻文件系统设计上的人为约束。例如，现在一个目录下可以容纳 100,000 个子目录。另一个使用 b* 树的好处就是 ReiserFS 能够像大多其它的下一代文件系统一样，根据需要动态地分配索引节，而不必在文件系统创建时建立固定的索引节。这有助于文件系统更灵活地适应其面临的各种存储需要，同时提供附加的空间有效率。

ReiserFS 有许多特征是特别针对提高小文件的性能的。和 ext2 不同，ReiserFS 并不固定地以 1k 或者 4k 的块分配存储空间，而是分配所需要的精确尺寸。而且 ReiserFS 也包括了以尾文件为中心的特殊优化 ― 尾文件是指那些比文件系统块小的文件及文件结尾部分。为了提高性能，ReiserFS 能够在 b* 树的叶子节点存储文件，而不是把数据存储在磁盘的其它地方再指向它。

这做了两件事。第一，它显著地提高了小文件的性能。由于文件数据和 stat_data（索引节）信息是紧挨着存储的，它们通常能被同一次磁盘 IO 操作所读取。第二，ReiserFS 能够压缩尾文件，节省大量磁盘空间。实际上，带有尾文件压缩功能（默认）的 ReiserFS 文件系统可以比同等的 ext2 文件系统多存储 6 个百分点的数据，这就其自身来说是令人惊叹的。

然而，由于在文件被修改时，尾文件压缩迫使 ReiserFS 重装数据，这就导致了性能上的轻微折损。鉴于这个原因，ReiserFS 尾文件压缩可以被关掉，允许系统管理员在速度与空间有效率上做出选择，或者牺牲一些存储能力来换取更高的速度。

ReiserFS 确实是一个非常出色的文件系统。在我的下一篇文章中，我将会指导您在 Linux 2.4 下完成 ReiserFS 安装的全过程。我们还将仔细地看一看性能调整，应用程序交互作用（和怎么围绕他们工作）以及使用的最佳内核等等。

小文件的性能

那么，如何能使文件系统更加适应环境呢？Namesys 已经决定着眼于文件系统的一个方面，至少最初是 ― 小文件的性能。通常，像 ext2 和 ufs 这样的文件系统在这一方面做的并不是很好，经常迫使开发人员转向数据库或者特别组织的处理来获取他们所需要的某种性能。随着时间的推移，这种“围绕问题进行编码”的方法怂恿了代码的膨胀和许多不兼容的特殊目的 API，这并不是好事情。

这儿有一个 ext2 如何鼓励这种编程的例子。ext2 很擅长存储大量大小在 20k 以上的文件，但是对于存储 2,000 个 50 字节的文件来说，它就不是一种很理想的技术了。当 ext2 必须处理非常小的文件时，不只是性能显著地下降，而且存储效率也同样下降，因为 ext2 是按 1k 或者 4k 的块来分配空间的（可在文件系统创建时设定）。

现在，常规的明智做法会提示您 不应该在文件系统上储存这么多小的文件。而是应该存储在某种运行在文件系统之上的数据库里。作为对这种说法的回应，Hans Reiser 指出无论何时您需要在文件系统的顶上建立一层，那就意味着文件系统不满足您的需要。如果文件系统满足您的需要，那么您首先就要避免使用特殊目的的解决方案。这样就可以节省开发的时间，并消除代码膨胀。这些代码可能是在您手动处理自己的个人存储器或者缓冲机制时，或者与数据库的某个库交互作用过程时所产生的。

理论上是这样。但是在实际运用中，ReiserFS 的小文件性能会是如何的好呢？好得让人吃惊。实际上，当处理小于 1k 的文件时，ReiserFS 大概要比 ext2 快 8 到 15 倍！更妙的是，这些性能提高并不以其它文件类型的性能损失为代价。通常，ReiserFS 几乎在各个方面都优于 ext2，但是在处理小文件时才真正体现出了其闪光点。

Apache 2.0在性能上的改善最吸引人。在支持POSIX线程的Unix系统上，Apache可以通过不同的MPM运行在一种多进程与多线程相混合的模式下，增强部分配置的可扩充性能。相比于Apache 1.3，2.0版本做了大量的优化来提升处理能力和可伸缩性，并且大多数改进在默认状态下即可生效。但是在编译和运行时刻，2.0也有许多可以显著提高性能的选择。本文不想叙述那些以功能换取速度的指令，如HostnameLookups等，而只是说明在2.0中影响性能的最核心特性：MPM（Multi -Processing Modules，多道处理模块）的基本工作原理和配置指令。

　　毫不夸张地说，MPM的引入是Apache 2.0最重要的变化。大家知道，Apache是基于模块化的设计，而Apache 2.0更扩展了模块化设计到Web服务器的最基本功能。服务器装载了一种多道处理模块，负责绑定本机网络端口、接受请求，并调度子进程来处理请求。扩展模块化设计有两个重要好处：

　　◆ Apache可以更简洁、有效地支持多种操作系统；

　　◆ 服务器可以按站点的特殊需要进行自定制。

　　在用户级，MPM看起来和其它Apache模块非常类似。主要区别是在任意时刻只能有一种MPM被装载到服务器中。

　　指定MPM的方法

　　下面以Red Hat Linux 9为平台，说明在Apache 2.0中如何指定MPM (Apache采用2.0.45)。先解压缩源代码包httpd-2.0.45.tar.gz，生成httpd-2.0.45目录（Apache 1.3源代码包的命名规则是apache_1.3.NN.tar.gz，而2.0版则是httpd-2.0.NN.tar.gz，其中NN是次版本号）。

　　进入httpd-2.0.45目录，运行以下代码：

 $ ./configure –help|grep mpm

　　显示如下：

–with-mpm=MPM
Choose the process model for Apache to use.
MPM={beos|worker|prefork|mpmt_os2| perchild|leader|threadpool}

　　上述操作用来选择要使用的进程模型，即哪种MPM模块。Beos、mpmt_os2分别是BeOS和OS/2上缺省的MPM， perchild主要设计目的是以不同的用户和组的身份来运行不同的子进程。这在运行多个需要CGI的虚拟主机时特别有用，会比1.3版中的SuExec 机制做得更好。leader和threadpool都是基于worker的变体，还处于实验性阶段，某些情况下并不会按照预期设想的那样工作，所以 Apache官方也并不推荐使用。因此，我们主要阐述prefork和worker这两种和性能关系最大的产品级MPM ( 有关其它的MPM详细说明，请参见Apache官方文档：http://httpd.apache.org/docs-2.0/mod/)。

　　prefork的工作原理及配置

　　如果不用“–with-mpm”显式指定某种MPM，prefork就是Unix平台上缺省的MPM。它所采用的预派生子进程方式也是 Apache 1.3中采用的模式。prefork本身并没有使用到线程，2.0版使用它是为了与1.3版保持兼容性；另一方面，prefork用单独的子进程来处理不同的请求，进程之间是彼此独立的，这也使其成为最稳定的MPM之一。

　　若使用prefork，在make编译和make install安装后，使用“httpd -l”来确定当前使用的MPM，应该会看到prefork.c（如果看到worker.c说明使用的是worker MPM，依此类推）。再查看缺省生成的httpd.conf配置文件，里面包含如下配置段：

StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0

　　prefork的工作原理是，控制进程在最初建立“StartServers”个子进程后，为了满足MinSpareServers设置的需要创建一个进程，等待一秒钟，继续创建两个，再等待一秒钟，继续创建四个……如此按指数级增加创建的进程数，最多达到每秒32个，直到满足 MinSpareServers设置的值为止。这就是预派生（prefork）的由来。这种模式可以不必在请求到来时再产生新的进程，从而减小了系统开销以增加性能。

　　MaxSpareServers设置了最大的空闲进程数，如果空闲进程数大于这个值，Apache会自动kill掉一些多余进程。这个值不要设得过大，但如果设的值比MinSpareServers小，Apache会自动把其调整为MinSpareServers+1。如果站点负载较大，可考虑同时加大MinSpareServers和MaxSpareServers。

　　MaxRequestsPerChild设置的是每个子进程可处理的请求数。每个子进程在处理了“MaxRequestsPerChild” 个请求后将自动销毁。0意味着无限，即子进程永不销毁。虽然缺省设为0可以使每个子进程处理更多的请求，但如果设成非零值也有两点重要的好处：

　　◆ 可防止意外的内存泄漏；

　　◆ 在服务器负载下降的时侯会自动减少子进程数。

　　因此，可根据服务器的负载来调整这个值。笔者认为10000左右比较合适。

　　MaxClients是这些指令中最为重要的一个，设定的是Apache可以同时处理的请求，是对Apache性能影响最大的参数。其缺省值 150是远远不够的，如果请求总数已达到这个值（可通过ps -ef|grep http|wc -l来确认），那么后面的请求就要排队，直到某个已处理请求完毕。这就是系统资源还剩下很多而HTTP访问却很慢的主要原因。系统管理员可以根据硬件配置和负载情况来动态调整这个值。虽然理论上这个值越大，可以处理的请求就越多，但Apache默认的限制不能大于256。如果把这个值设为大于256，那么 Apache将无法起动。事实上，256对于负载稍重的站点也是不够的。在Apache 1.3中，这是个硬限制。如果要加大这个值，必须在“configure”前手工修改的源代码树下的src/include/httpd.h中查找 256，就会发现“#define HARD_SERVER_LIMIT 256”这行。把256改为要增大的值（如4000），然后重新编译Apache即可。在Apache 2.0中新加入了ServerLimit指令，使得无须重编译Apache就可以加大MaxClients。下面是笔者的prefork配置段：

StartServers 10
MinSpareServers 10
MaxSpareServers 15
ServerLimit 2000
MaxClients 1000
MaxRequestsPerChild 10000

　　上述配置中，ServerLimit的最大值是20000，对于大多数站点已经足够。如果一定要再加大这个数值，对位于源代码树下server/mpm/prefork/prefork.c中以下两行做相应修改即可：

#define DEFAULT_SERVER_LIMIT 256
#define MAX_SERVER_LIMIT 20000

　　worker的工作原理及配置

　　相对于prefork，worker是2.0 版中全新的支持多线程和多进程混合模型的MPM。由于使用线程来处理，所以可以处理相对海量的请求，而系统资源的开销要小于基于进程的服务器。但是， worker也使用了多进程，每个进程又生成多个线程，以获得基于进程服务器的稳定性。这种MPM的工作方式将是Apache 2.0的发展趋势。

　　在configure -with-mpm=worker后，进行make编译、make install安装。在缺省生成的httpd.conf中有以下配置段：

StartServers 2
MaxClients 150
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 0

　　worker的工作原理是，由主控制进程生成“StartServers”个子进程，每个子进程中包含固定的ThreadsPerChild 线程数，各个线程独立地处理请求。同样，为了不在请求到来时再生成线程，MinSpareThreads和MaxSpareThreads设置了最少和最多的空闲线程数；而MaxClients设置了所有子进程中的线程总数。如果现有子进程中的线程总数不能满足负载，控制进程将派生新的子进程。

　　MinSpareThreads和MaxSpareThreads的最大缺省值分别是75和250。这两个参数对Apache的性能影响并不大，可以按照实际情况相应调节。

　　ThreadsPerChild是worker MPM中与性能相关最密切的指令。ThreadsPerChild的最大缺省值是64，如果负载较大，64也是不够的。这时要显式使用 ThreadLimit指令，它的最大缺省值是20000。上述两个值位于源码树server/mpm/worker/worker.c中的以下两行：

#define DEFAULT_THREAD_LIMIT 64
#define MAX_THREAD_LIMIT 20000

　　这两行对应着ThreadsPerChild和ThreadLimit的限制数。最好在configure之前就把64改成所希望的值。注意，不要把这两个值设得太高，超过系统的处理能力，从而因Apache不起动使系统很不稳定。

　　Worker模式下所能同时处理的请求总数是由子进程总数乘以ThreadsPerChild值决定的，应该大于等于MaxClients。如果负载很大，现有的子进程数不能满足时，控制进程会派生新的子进程。默认最大的子进程总数是16，加大时也需要显式声明ServerLimit（最大值是20000）。这两个值位于源码树server/mpm/worker/worker.c中的以下两行：

#define DEFAULT_SERVER_LIMIT 16
#define MAX_SERVER_LIMIT 20000

　　需要注意的是，如果显式声明了ServerLimit，那么它乘以ThreadsPerChild的值必须大于等于MaxClients，而且MaxClients必须是ThreadsPerChild的整数倍，否则Apache将会自动调节到一个相应值（可能是个非期望值）。下面是笔者的 worker配置段：

StartServers 3
MaxClients 2000
ServerLimit 25
MinSpareThreads 50
MaxSpareThreads 200
ThreadLimit 200
ThreadsPerChild 100
MaxRequestsPerChild 0

　　通过上面的叙述，可以了解到Apache 2.0中prefork和worker这两个重要MPM的工作原理，并可根据实际情况来配置Apache相关的核心参数，以获得最大的性能和稳定性。

其它更详细的写以到http://httpd.apache.org/docs-2.0/

先打开一个,vi 文件名
然后在vi的命令输入状态下输入
:sp 另外一个文件的路径及文件名

如此就可以在一个窗口打开3个文件了。
可以使用 ctrl ＋ 两次按 w
在3个文件中切换