DaNmarner的中文博客

这是最终修正版，如果还有问题，我会继续修正……首发于 Twitter。咆哮者系本人。

点击可以看大图。

更新10.6.6失败了以后开始找寻全盘备份黑苹果的方案，然后就找到了神奇的 clonezilla 。用它把刚刚装完雪豹的分区备份下来，以后就可以“一键恢复”了。

先简略介绍一下这个软件的几大特点：

1. 开源。代码在 sourceforge 。其实是个基于 Debian 的 Linux 发行版。

2. 由台湾牛人开发，支持中文，相信对很多朋友来说是很重要的。

3. 操作傻瓜化。

4. 最重要的，功能强大。具体表现在支持 HFS+ 和 NTFS 等等各种格式的全盘/分区备份。同时备份MBR信息，所以不用担心 bootloader 丢失。Server 版本还支持多机部署。程序本身也可以运行在 Windows 或者 Linux 下面。

下面介绍一下单机版 （clonezilla-live） 在 Linux 下的使用过程：

有系统镜像制作或使用经历的人想到的第一步应该是“启动介质”吧？ 它可以是一张光盘，一个U盘或者外接USB硬盘。

clonezilla 也要求使用这样一个介质，准备它的过程简单到了极点：只要根据你的操作系统下载这个叫做 Tuxboot 的图形化小工具。插入你准备使用的启动介质，打开 Tuxboot，在界面的"type"部分选择你的介质，然后点"OK"。Tuxboot 会自动下载合适的 clonezilla 并安装到你的介质上，并把它设置成一个启动介质。注：这些下载涉及到 sourceforge，可能需要翻墙。

Tuxboot界面很简洁，如下图：

clonezilla 大概 100+MB 的样子，下载过后的安装过程很快。

如果你对这种全自动过程放心不下，也可以在官网找到手动安装的步骤。

启动介质做好以后的事情就简单多了，插入启动介质（比如U盘）到你想备份的系统分区所在的机器，（对我来说是装了黑苹果的华硕 1005ha 上网本），重启，选择从该介质启动。看到一个类似 Grub 的菜单。在这里可以选择语言。然后会进入文字菜单的界面，选择制作还是恢复镜像，镜像的保存位置和来源，镜像文件分隔体积等等，跟着提示操作就行了。我用了专家模式，没有碰到任何意外。

一个 35G 的 HFS+ 分区镜像大概花了45分钟就做好了。生成的镜像有 15G 左右（根据选择的压缩模式不同可能比例也不一样）。

以后再碰到黑苹果升级失败就不用重头装了，估计 Linux 甚至 Windows 也用的上吧。

DaNmarner 在 Hacker News 最近关于 Vim 插件的 帖子 回复中了解到一个叫做 pathogen 的 Vim 脚本，其作用是改善 Vim 管理插件的方式。 试用过后发现 pathogen 果然强大。是以撰文分享。

问题剖析

可扩展性是优秀软件的重要特点之一，而 Vim 从 Unix 系统一路传成下来更是将可扩展性发挥到了极致。 相信多数 Vim 的经验用户除了自己经精心维护的 .vimrc 配置文件之外更是有一个用起来得心应手的插件宝库，从而让 Vim 满足自己五花八门的使用需求。

Vim 大行其道，除了优秀插件众多之外的另一个因素是插件机制的简便易用。 安装插件的方法无外乎一下载二解压，或者下载以后用运行 Vim 里的安装命令。 没有特殊指定，插件都是装载 ~/.vim 目录之下。 通过复制，symlink 甚至版本控制工具把这个目录备份一下，日后更是能在不同机器上瞬间找到熟悉的编辑环境。

可是时间一久，这个 ~/.vim 目录难免变得越来越臃肿，各类插件横七竖八的散落在那一个个 autoload，ftplugin, indent，syntax,doc 等目录里面不说，很多插件还我行我素的自己创建一堆私有目录，占山为王。 等到你想删除或更新某某插件的时候，要么得去重新下载插件的压缩包，找到它的五脏六腑都安插在了什么位置，要么只能凭着瞎猜法门一个目录一个目录的去找来。

解决之道

pathogen 让每个插件占有一个单独的目录，解决插件文件分散的问题。 安装了 pathogen 以后只要在 ~/.vim （注：MS Windows 下貌似是 ~\vimfiles，下同）里建立一个 bundle 目录，然后把所有插件一一放在 ~/.vim/bundle/插件名 下面，就可以使用。 插件的安装过程与没有 pathogen 时类似，但从安装结束开始，一切的插件管理过程都能得到简化。

试用过某个插件以后需要删除？安装在 bundle 目录里最后把插件的目录一删了之就行了。

想保持使用某个插件的最新版本？直接从插件的仓库 checkout 一份代码到 bundle 目录，或者别的地方再 symlink 一下就行了。

想了解一下这个插件的实现方法？有了 pathogen 去哪里找插件脚本再也不是问题了。

实战演练

pathogen 只有一个单独的脚本，所谓安装就是把它放在你的 ~/.vim/autoload 目录。

如果你有一个类 Unix 环境（Linux, Mac OS X），只需要下面这一条命令：

wget -O ~/.vim/autoload/pathogen.vim http://www.vim.org/scripts/download_script.php?src_id=12116

要启用它，还要在 .vimrc 文件里, filetype plugin indent on 之前的任何地方，加入下面这句：

call pathogen#runtime_append_all_bundles()

这样就搞定了，把常用的插件都重装在 ~/.vim/bundle 里面吧！ DaNmarner 个人喜欢直接把插件从仓库里 checkout 出来，以后直接通过版本控制来更新 Vim 插件。 以 NERDTree 这个插件为例，安装起来是这样的：

git clone http://github.com/scrooloose/nerdtree.git path/to/code/nerdtree

ln -s path/to/code/nerdtree ~/.vim/bundle/nerdtree

更新到最新版本：

cd path/to/code/nerdtree && git pull origin

删除该插件：

rm -rf ~/.vim/bundle/nerdtree

怎么样，有了 pathogen ，管理 Vim 插件是不是简单了很多？

本文作者为 DaNmarner，原文发表于 http://blog.danmarner.com/me/entry/vim-pathogen/ ，转载请保留原文出处与链接。

今天调试一个只有部署到 GAE 后才出现的 bug 时发现 appcfg 不知何故每次部署都要问我用户名密码。

而为了调试这个 bug ，我又不得不用 logging 跟踪 Django 在运行过程中产生的一些变量值，然后部署到 GAE ，然后去后台看 logging 的结果。

每次输入用户名和密码在这种情形下咱可折腾不起。于是看了一下 appcfg.py 的帮助，发现 update 有 -e 和 --passin 这两个选项。前者用来指明上传用的 Google 帐号，后者指明从标准输入 获取密码。所以用下面这一行命令就可以省掉部署过程中输入用户名密码的步骤了::

echo your_password | appcfg.py update -e your_username@gmail.com --passin

有了这个，就可以进一步写一些 vim 快捷键之类的脚本，更好的自动化 GAE 应用的部署过程了。不过要小心保护包含这条命令的脚本，因为里面有你的秘密哦。

Git 是 Linux 之父 Linus Torvalds 编写的分布式版本控制系统。它最初是用来取代商业软件 BitKeeper 管理 Linux 内核开发的。

与其他版本控制系统相比，Git 有很多优势，具体内容可以参照不久前我，chunzi以及其它几位译者翻译的「Pro Git」。本文着重讨论 Git 的杀手锏：分支特性。

Git 储存版本历史的方式是为每一次 commit 时的整个目录储存一个快照。而一个 Git 分支实质上是一个可以在不同版本快照之间移动的指针。所以创建和储存分支在 Git 管理过程中是异常的轻便。

轻便的分支结构意味着开发时更频繁的使用分支。而实际上 Git 社区正是使用分支最泛滥的。Git 鼓励用户创建分支：所有的代码最好都在分支里写成，最后合并到主干代码中。一个分支可以是一个实现思路的实验场所，或者一个修复补丁。分支存在的时间可以很短，可能只包含一两次提交，而一旦合并到主干就被立刻删除。Git 的分支是给开发者享受用的，而不是...等等，也是为项目管理代码用的！

说到这我们其实遇到了 Git 的分支哲学为人垢病的一面。传统上在类似Subversion 这样的集中式版本控制系统里，分支基本上有三种使命：1 同时维护不同版本；2，进行重大特性的开发；3，控制特定开发者的提交权限。无论是履行哪一种使命，传统分支一定是为了＂长期＂存在而建立的。这里的长期当然是相对多数 Git 分支的寿命而言，即使某个分支停止使用了，一般也会转移到 attic 下面作为历史的一部分永久保存。

当然，Git 的分支完全可以，并且在实践中也经常完成相同的任务。但是 Git 本身并没有对「协助开发的分支」和「用于管理的分支」这二者进行区分。这对于刚加入项目开发的新人理解版本控制的流程非常不利。

另一方面，这个两种功能一种实现的设计也打破了个人 hack 和传统上分支中央集权的界限：当分支成了每天的家常便饭的时候，开发者的心理负担也少了，从而提高了他们为项目作贡献的积极性。这和 Git 植根于开源社区是紧密相联的。

所以 Git 没有解决这个问题，可以看作是一种缺失，也可以看作是一项特性。

怎样使用分支归根结底是人的问题，人的问题再好的工具也没法彻底解决。当有人问 Django 的核心为什么 Django 还在使用 svn 而不是 Git 或者 hg 时，他们是这样回答的：＂更换到其它的 VCS 不会为 Django 开发流程带来丝毫的改变，官方仓库还是那个唯一的仓库，提交权限仍将限制在核心成员手中，无论那是个git，svn 还是hg仓库。＂DaNmarner 觉得这一席话是以上观点的最佳表述。