Becomin' Charles

最早的版本控制就是将文件拷贝一下，放到用不同时间戳命名的文件夹中。在此基础上出现了本地版本控制系统，基本原理就是用数据库等存储，将文件的每一个版本的保存下来，实现了本地的自动化版本控制系统（VCS=Version Control System）。

后来，人们产生了与别人协作，共同编辑文档的需求。由此，衍生了一种架构，使用一台单独的计算机作为服务器，专门管理文件的所有版本，这种结构，就叫做中央版本控制系统（CVCS = Centralized VCS）。这种架构一度成为了版本控制系统的事实标准。典型的有CVS，Subversion等等优秀地工具。

中央版本控制系统有诸多优势：

1. 及时了解他人进度；
2. 控制每个人对特定文件目录的读写权限；
3. 更容易管理项目的代码文档；

事物总是具有其两面性，缺点也不可避免：

1. 如果中央版本控制服务器荡机，则所有人无法提交文件；
2. 如果中央服务器硬盘损坏，将丢失全部版本信息，本地版本控制系统也有这个问题；

为了能够规避上述的风险，那么我们需要把鸡蛋放在多个篮子里，于是，就要有冗余，于是就产生了分布式版本控制系统（DVCS = Distributed VCS）。代表产品有Git，Mercurial，Bazaar，Darcs等。在这种结构中，也有一台中央服务器，保存所有的文件及版本，不同的地方在于，每个客户端在从服务器检出版本的时候，都会将全部版本库拷贝一遍，每一台机器上包含的都是一个完整的版本库。在这种情况下，如果服务器发生问题，那么每一个客户端，都可以轻易恢复整个版本库，杜绝了CVCS带来的风险。

Git的由来

Linux内核是一个大型项目，有无数的开发者工作在其中，从2002年开始，Linux内核项目使用了分布式版本控制系统BitKeeper，但是从2005年开始起，Linux内核开发社区和提供BitKeeper的商业公司关系恶化，Linux对BitKeeper的使用不再免费。于是这种状况激励了开发者（主要是Linus Torvalds）去研发属于自己的分布式版本控制系统。从2005年开始起，Git诞生了。

1. 速度快；
2. 设计简单；
3. 对非线性开发的强大支持（数千分支并行开发）；
4. 完全分布式；
5. 能管理大型项目，像Linux内核这样的（对数据占用空间和同步速度有较高要求）；

Git与普通CVCS最大的不同在于，Git存储的不是文件的差异，而是存储文件本身。Git分布式特性决定了在Git中的绝大多数操作都是本地动作，就好像是在文件系统中读取一个文件那样简单，所以，也就有了近乎极限的速度。同时，这种特性还给用户提供了在断网情况下继续工作的可能性。

Git的安装

可能Git还有很多的好处，但是我估计看到此文的您跟我一样没有耐心去了解那些东西，赶快装上体验一下才比较实惠。不得不说，在Windows下安装*nix世界的软件是痛苦的，尤其是像Git这样年轻的软件，那过程真的是相当痛苦。

以前用过SVN，在Windows下的SVN有好多版本，最著名的就是TortoiseSVN，那真是无敌好用，基本上不要你对SVN的命令有什么详细的了解，你就可以非常愉快地使用了。真对Git，同样有一个TortoiseGit，但是，千万要小心了，这个可并非那么好用的。

首先，就算你想使用TortoiseGit，你也必须安装“原版”的Git。所以，不要抱有侥幸，请直接去http://git-scm.com/download下载for Windows的版本，我选择的是msysgit，这个东西很有特色，是在你系统上安装了一个MINGW32（Windows下的Linux命令环境），然后在这个环境下，用gcc现编译了一个git出来，所以官网特别强调了“这不是一个为Windows设计的第三方版本，而是git本身”。

装完这个的第二步才能轮到TortoiseGit等GUI扩展，这篇文章里暂时先不介绍了，因为我装完了以后，发现根本不能用。还是直接用git命令行比较好。

下载msysgit的时候，有好多版本可以选择，第一个原则是选择最新的，如果安装包表明是网络的，那么是通过安装过程中从网上下载源码的，否则就是带有源码拷贝的，我选了完整安装包，就是不需要网络下载的。双击安装，首先解压缩到磁盘上，自动启动MINGW32环境，开始编译，安装，都是自动的，全部结束后，会提示运行 /share/msysGit/initialize.sh，在msysgit目录下运行msys.bat，你会得到一个命令行，然后执行：

cd /share/msysGit/

./initialize.sh

以上两行命令执行后，会开始联网下载若干命令，把整个msysgit目录都纳入到了git的管理之下，现在刚开始学，我想这个东西不用管了，执行了命令成功后，就算是有了一个可以开始实践的平台了。

在插件管理页面，每个插件下面有2-3个Action link，包含了用户可以对该插件进行的几种操作。在插件为禁用状态时，可用的操作有：Activate（启用），Edit（编辑），Delete（删除）；在插件为已经启用的状态下，默认有两个可用的操作：Deactivate（禁用）和Edit（编辑）。如果我们在这个列表里仔细观察，就会发现，有些插件会多出一个Settings（设置）操作。本文记录了，为插件添加Settings link的方法。没有什么过多的描述，直接放代码了。在插件主要文件中（包含了插件信息注释语句的那个文件），使用下面的代码，就可以为这个插件添加一个Settings link了。

1
2
3
4
5
6
7
8
9

   function fmp_add_setting_link( $links ) {
       $links[] = 'Settings'; //怎样构造这个link呢？大家可以自己想想
return $links;
}
if(is_admin()){
add_filter( 'plugin_action_links_' . plugin_basename( __FILE__ ), 'fmp_add_setting_link' );
}

Apache的虚拟主机是一种允许在同一台机器上，运行超过一个网站的解决方案。虚拟主机有两种，一种叫基于IP的（IP-based），另一种叫基于名字的（name-based）。虚拟主机的存在，对用户来说是透明的。

WP的插件在开发完成后，会在用户的服务器上运行，而用户的服务器环境基本上可以用千奇百怪来形容。开发过程中，在本地运行得好好的插件的，一旦安装到用户的服务器上，也有可能变得无法运行。

所以，作为WP插件的开发者，最好不要对插件最终的运行环境做任何假设。而且，最好能够在插件被启用的时候，进行必要的检查，给用户以提示，对于自己没法兼容的问题，应该明确指出，避免用户遭遇不必要的麻烦。

在我个人的WP插件开发过程中，我主要遇到的问题，基本上都是PHP相关的问题。

插件的后台管理页面的主要功能是协助用户设定插件运行时参数，一般都需要用户进行交互，这就少不了需要客户端脚本的参与（主要是js脚本，当然还有配套的css样式表）。

WP的后台本身就已经加载了许多的脚本，包括各类类库和基础功能的脚本。过多的脚本文件引入，会增加HTTP请求，增加流量，拖慢速度。好在，WP的后台已经采取了相当多的措施，来管理后台加载的脚本。首先是用wp-dependency管理依赖关系，用load-scripts来压缩、并加载脚本，使得各种类库被合并到同一个文件中进行加载，节省了HTTP请求数量和流量。

man是 Linux 下最最常用的命令之一，用来显示某个命令的手册。

一般在命令行下，manpages 通过粗体和下划线来标记关键信息，有多种方法来使man命令显示彩色的 manpages。

man是调用less来显示 manpages 的，可以更换这个程序，使用most来显示，这是一个方法。但是长期以来使用less，已经习惯，most又有一套操作方法，后来我又发现了一种方案，非常简单，只要通过在.bashrc中设定环境变量，就可以高亮彩显 manpages，非常方便。

设定方法如下，在.bashrc 末尾添加如下几行：

1
2
3
4
5
6
7

export LESS_TERMCAP_mb=$'\E[01;31m'
export LESS_TERMCAP_md=$'\E[01;31m'
export LESS_TERMCAP_me=$'\E[0m'
export LESS_TERMCAP_se=$'\E[0m'
export LESS_TERMCAP_so=$'\E[01;44;33m'
export LESS_TERMCAP_ue=$'\E[0m'
export LESS_TERMCAP_us=$'\E[01;32m'

如此，即可以为 manpages 添加红绿两色，虽然不多，但是远好过了单调的黑白页面。

从 Word97 开始就用上 MS Word 了，直到 Word2007，一晃眼也用了 10 多年了，可惜嘛，依旧是那个烂水平。排版个学位论文啥的，就是我水平的极限了。Word 是一款强悍的编辑排版软件，可惜，我实在钻研精神有限，实在惭愧。现在又到一年学位论文时啊，想着今后漫长的日子里，要憋好几十页的文章，一种孤独寂寥的感觉就涌上心头，实在是不甘心，这就又想起来，有一款排版效果堪比 Word，搞不好还略有小胜的软件，我还完全没有涉足过，这就是 LaTex 了。学习新东西给人的那种新鲜喜悦，可以好好中和一下憋论文的悲苦，于是我踏上了 LaTeX 之旅。

LaTex 一般指的就是 LaTeX 2e，是一个在 TeX 基础之上编写的宏包。关于 TeX 的起源，还有一段佳话，我就不赘述了。乍一接触 LaTeX，无论是由于任何原因，也免不了要把这个软件和 Word 相比较，我同样不能免俗。要说二者的差异，最大的地方还是理念上的差异了，关于这种差异，我同样不想赘述。我只谈体验。LaTeX 无论是学习，还是编写文档，初上手给人的感觉就两个字，痛苦。

我在 CSDN 上分享了很多东西，一直想把那个列表也在博客上罗列一个，一直就没有付诸于行动，昨天一发狠，终于弄了。

等于昨天几个小时，今天几个小时，搞出了一个小插件。就是右侧的一个小挂件。点上去就会链到 CSDN 的下载页面。

算是我把一年前的债还了。真开心。

插件里面没什么技术含量，就是小小调用了一下 Google Feed API。

做这个插件，也引发了我一个思考。

能否在页面的 head 部分，就知道这个页面会装载哪些 Widget 呢？昨天折腾了半天，也没有解决这个问题。

解决的好处是显而易见的，现在的 Widget，大多数都需要js来辅助了。但是很多高端的主题有数个 sidebar，每页不同，如果 Widget 开发者，为了符合 Web 标准，把 js 放在 head 部分，就不得不无差别地在所有页面插入代码了。那样的话，添加一个 Widget 就会带来浪费的流量，页面速度也会被不断拖慢。

当然有个替代方案是把代码放到页面的 footer 部分，不过，个人以为，只要脚本出现在了Html body里面，那么直接嵌入到 Widget 中和 hook 到 footer 上，其实没什么本质区别，都破坏了行为和数据分离的原则。

这也是无奈之举了。谁叫 WP 设计成了 sidebar.php 执行前，无法知道页面会载入哪个 sidebar 这种结构呢？

当然，不排除还有更好方法的可能，如果知道的网友还望不吝告知。

初次安装vim编辑器时，我们必须要配置~/·vimrc文件才能让vim变得更加好用。最少最少，你要配置下面一些内容：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

" 不再与老旧的Vi兼容 set nocompatible " 开启filetype支持 filetype on filetype plugin on filetype indent on " 语法高亮 syntax on " 这个选项为什么不是默认的？ set hidden " 执行宏的时候不要更新显示set lazyredraw " 至少让你知道当前是在什么状态下 set showmode " 启用增强的命令行自动补全。必须再编译时开启 +wildmenu 选项 set wildmenu " 更容易的编辑此文件，即vimrc文件。用ev命令表示edit vimrc。 nmap <silent> ,ev :e $MYVIMRC<cr> " 并且令配置立刻生效，用sv命令表示source .vimrc nmap <silent> ,sv :so $MYVIMRC<cr>

==========

上面一些选项还有很多我不懂的，以后研究明白了再添加解释。此文就作为我学习使用vim编辑器的起点吧~~

本文将介绍一个最为简略的搭建SVN服务器的方法。