翻译是体力活

翻译一本书着实很累。每一次 commit 都累积了几个小时的劳动。还好有团队,相互鼓励和扶持,才能保证进度和质量。一次次地修订,读上一版本的翻译,修订或是增加新版的翻译,然后自己审校,再交叉审校,再通读审校,最后还要对别人的每次更新再复阅,数也数不清了。但即便如此,总还担心有漏网之鱼,或者将来有读者诟病这里那里的问题。

继续。还有 70 个 rev 需要 review 下。Thanks Joe! Thanks Hui! Thanks Qiang!

用 git 保存空目录

git 和 svn 不同,仅仅跟踪文件的变动,不跟踪目录。Perforce 也是如此。所以,一个空目录,如果里面没有文件,即便 git add 这个目录,另外在别处 check out 的时候,是没有这个空目录的。

只跟踪文件变化,不跟踪目录,这么设计是有原因的。但这会带来一些小麻烦。有时候,确实需要在代码仓库中保留某个空目录。比如测试时需要用到的空目录。

变通的解决办法是在空目录下存一个 .gitignore 文件。然后 git add 此目录后,相当于跟踪了 .gitignore 文件,产生的“副作用”就是这个“空”目录也纳入“跟踪”,最终的效果是可以 check out 出一个看起来空空的目录。如果有许多这样的空目录,可以用下面的命令自动补充 .gitignore 文件:

$ find . \( -type d -empty \) -and \( -not -regex ./\.git.* \) -exec touch {}/.gitignore \;

递归找寻当前目录下,类型为目录,且为空,也没有 .git 开头的文件,在其中用 touch 新建一个空的 .gitignore 文件。然后 git add . 之后即可。

如果这些特殊文件会对测试带来干扰,那就只好在测试程序运行具体测试项目之前,先跑一段初始化目录结构的代码。另外可能还需要编写负责清理的代码。

Google Ads

不靠谱

这年头没什么靠谱的东西,特别是电脑上的数据。放在自家硬盘上,可能哪天硬盘咯吱一声就不认了。放在光盘上,不消几年,就可能读不出来。放在 usb 上,说不定哪天就丢在某个小角落里了。放在以前公司的服务器上,人家一闹纠纷,拔掉网线什么都没了。

以前用 svn 管理代码和文件,有次服务器硬盘出坏道,结果 svn 仓库中有个文件读不出来,check out 出来的数据也不完整。后来诚惶诚恐改用 git 无处不仓库。结果时常搞不清楚哪个最新哪个还没更新。

于是,开始狡兔三窟。无处不 rsync。

git 之初体验

  • 目前对于 git 只是了解了些皮毛,略有体会。
  • git 速度超快。因它对所有对象都打包压缩起来统一放在仓库里。
  • git 只维护文件。这点和 Perforce 相同。svn 则可以维护目录。所以 svn 对于每个跟踪的目录都嵌一个隐藏的 .svn 目录保存跟踪信息。而 git 和 Perforce 则只在统一的一个地方内维护文件版本。
  • git 作为分布式代码管理工具,无处不仓库。所以每次 git commit 都只对本地仓库提交,要发布到公共仓库或者备份仓库,则需要 git push。用惯了 svn 比较容易疏忽第二步。
  • git 更适合广泛地引入他人的贡献。对于 svn,通常贡献者要主动联系到项目组或者作者,获取相应的 svn 帐户后,再行协作。而对于 git,贡献者根本无须事先联系,即刻在 clone 的仓库中开始自己的工作,待完成后通过邮件提交 patch,此后项目维护者可以在新的 branch 中合并 patch 并测试,通过的话再并入主干。这种“先做了再说”的行事态度极大的鼓励和推动了 geeker 们的热情和创造力。这同 wiki 的开放思想有着异曲同工之妙。
  • git status 的输出不如 svn status 直观。很不习惯。或许可以 hack 一下,慢慢再说。
  • git 比 svn 更强调 branch 的概念。以前使用 svn 不太会想起来有 branch 这件事。在 git 里就要时刻保持着“我现在在哪个 branch 里做事,这个 branch 是管什么事的”这样一种概念。因为从实现上,svn 通过复制目录创建一个分支,你可以在工作目录中看到这个 branch 的目录;而在 git 中,则完全用 ref 来指代当前所在的 branch,你可以选择和跳跃,然后就可以看到当前的工作目录里的内容就变化为该 branch 的内容了。显然,这是对 svn 在管理分支时仅采取目录模拟这种简单手法的改进。当然 git 的 branch 管理不仅于此,还有 rebase 等 fast forward。
  • git 听起来就比 svn 酷。

新站开张

原来的服务器硬件故障,拆了硬盘换到另一台测试机器上,竟然不认网卡,再挂到 FreeBSD 机器上,一写数据就断开了原先 mount 上的分区,好不容易 fsck 之后导出了 svn 仓库的数据,又发现若干文件有损坏,在另一台 FreeBSD 机器上配置 WordPress 又碰到 php5-mysql 编译出错,郁闷死了。 决定不能在 svn 一棵树上吊死。决定不用 WordPress 苟且偷生。 昨天花了点时间研习了下 git。没完全搞明白,不过暂时已经能用起来了。今天花了半天时间,把原来的 blog 里面的数据导出来,重新用 Catalyst 作了一个站,这就跑起来了。 出于格式自由的缘故,写了这个目前不算是 blog 的站点。我想适时的时候用 pod 或者 Textile 或者 wiki 格式写,同时不想让所见即所得的编辑器给我横加减些东西。出于对服务器要求自由的缘故,不使用数据库,直接将文章以文件的形式保存。这样另外有个好处,就 是我可以用 git 来维护这些文章,不必担心单点故障。也可以非常方便地发布成静态页面的站点,就像 MT 那样。 好了,回家休息。

sshfs

客户的机器是 FreeBSD 两年多前配的,内网,无法连接到外部,只有 cvs 没有 svn。希望在该服务器上修改代码测试,也希望使用 svn 管理和维护。罪敏捷的方法就是用 sshfs 挂接,然后在本地 ubuntu 的文件系统上进行 svn 操作和更新。实践证明行之有效,服务器不用作任何改动,只需要一如既往提供 ssh server。 sshfs 就是通过 ssh 连接挂载远端文件系统的工具,基于 fuse 软件。ubuntu 下面只需要安装它并将自己用户加入 fuse 组:

$ sudo apt-get install sshfs
$ sudo adduser chunzi fuse

然后重新登录下就可以用:

$ mkdir remote
$ sshfs username@server:/path/to/remote/fs remote -o workaround=rename

后面的参数用来在 svn up 的时候可以自动更新文件。

Perforce 点滴

我恨 Perforce。虽然它更快更强大,不过着实是为机器考虑,人用起来不直观,也麻烦。

如果要添加一个目录,Subversion 只需要:

$ svn add directory_name
$ svn ci -m 'adding ...'

Perforce 根本不对目录进行版本管理,所以没有类似的添加命令。Perforce 永远只对文件进行版本跟踪。添加一个文件之后,那么这个文件的路径决定了所在的那些目录也同时被“添加”到仓库中。由此引来一个问题,删除文件后留下的空目录就要手工删掉。虽然这些空目录不影响仓库,不过这样多少体现了仓库和工作目录的不一致性,比较容易让人 confusing。所以 Perforce 里面添加目录就只有一种方法,依次添加所有其中的文件。这是一件苦差事,所幸还有条捷径:

$ cd directory_need_add
$ find . -type f -print | p4 -x - add
$ p4 submit

类似的删除目录的操作也是如是,把 add 换成 delete。

此外最讨厌的是不知道本地修改了什么文件(如果事先没有 p4 edit file 作声明的话),以及哪些文件还没有纳入版本控制。Subversion 简单,只需要 svn status 就可以从首字母看到状态。Perforce 没有从人的角度考虑这些问题,所以只能多走几步:

$ find . ! -type d | xargs p4 have 2>&1 > /dev/null

麻烦呀麻烦。

开始 Perl Testing 一书的翻译工作

终于,正式地,开始了这项翻译工作。《Perl Testing – A Developers Notebook》这本书虽然不算厚,也不算艰深,但要做好翻译并非易事。甚而有些诚惶诚恐。

花了一些时间,目前已经准备停当,可以全身心投入翻译工作了。项目的构架基本上是用 Subversion + Trac + Google Groups。在原始 docbook 格式基础上用 po 格式对照翻译。出于保密协议,所以这一切仅限于项目成员。希望最终的成书不要被世人斥为机器翻译,我的要求不高,至少大多数人说还行就行。

准备这些的时候,稍稍深入地了解了些 docbook 相关的知识,并摘录到:http://del.icio.us/chunzi/docbook 。这时候才发现 del.icio.us 如此好用,以前怎么没觉得呢?后知后觉。又看了些 po 格式的资料,发现 po 天生是用来帮助应用程序做国际化的,如果要翻译类似书籍或者文章之类讲究顺序的东西的时候,po 的编辑器就不那么好用了。比如说 gtranslater 和 poedit。它们都会孤立得看待每一个词条,完成翻译的条目会强制转移的别的位置,这让我很郁闷。所以最终还是用 gedit 直接编辑 po 文件,也没什么特别不方便的地方。

其实原来并不要求用 docbook 来做,而我希望能够表现的更加专业,所以一再要求提供 docbook 格式。如此,一切都变得那么井井有条,快速而优雅。除了转换到 pdf 格式还有些问题(暂时并不需要也不重要)。剩下要做的,就是推敲再推敲。

路漫漫其修远兮,吾将上下而求索。

Perforce 第一印象

不好。

因为我更喜欢 Subversion,意图明确干净。p4 用起来好罗嗦,checkout 还要先给出模块名,然后 sync 出来,不如 svn co 那样清爽。svn mv 的工作硬要

$ p4 integrate old new
$ p4 delete old
$ p4 submit

这样一番劳累才行。

公司这次全面将 CVS 切换到 Perforce,早上收到 manager 的预告信,下午就放出了相关的资料。不过大公司果然有大派头,这次迁移,非但给出了详尽的使用文档和规范,还提供了供学习和测试的服务器,另外还为不同客户端制作了安装脚本,同时放出各个命令操作的视频教程,真可谓用心良苦啊。早上建议使用 Subversion + Trac 的建议算是流产了。不过刚开始有所了解,希望日后能有新的良好体验。

爱死 Ubuntu

老早就知道 Ubuntu,也听闻不错。因为开发时需要 IE 浏览器调试,所以一直籍着这个借口,没有怎么玩 Ubuntu。说起来惭愧,每次装好了,过几天觉着没什么用就删了。

这回新的公司,大抵上不再做 web 开发了,主要还是用 ssh 登入到国外公司的内部服务器上,然后用一堆 Unix 命令干活。所以从开始的时候,尝试着使用 Ubuntu 当作桌面,然后架构本地的开发测试环境工作。此时的 Ubuntu 已经是 6.10 版本,中文的输入已经让我满舒服了,字体的显示虽然没有 Windows 下面的完美,不过也还是可以接受的。经过一番折腾之后,顿然发现自己已经爱死 Ubuntu 了。Ubuntu 让一切变得自然流畅,简洁大方,他让我觉得自己是可以掌控一切的上帝。这种感觉实在太美好了。

用 Cisco 的 vpnclient for linux ,一个命令直接连接到美国总部的内网。使用一个简单的 alias 过的 ssh-dev3 命令直接连接到开发服务器上,配置过 key 之后甚至不用输入密码。调远程的文件直接 scp 就行,还可以通过 sftp:// 的方式在文件浏览器中直接查阅远程的文件,然后用 gedit 编辑,或者直接在 gedit 中打开 uri 资源。而 gedit 的 snippet 插件让我随时可以定义需要快速扩展的代码片段。使用一个 Gaim 连接公司内部的 jabber 服务器,以及同时连接 gtalk, msn, yahoo message。想去的 irc 站点,就开一个终端窗口,运行 irssi 命令。用上系统的快捷键,定义 windows 键直接打开终端窗口。用 Evolution 设置好通过 IMAP 方式连接公司的邮件服务器,那样不管在家还是公司,都可以不用担心丢失什么。用 Amarok 听音乐,自在而舒适。要装什么软件, aptitude search 一下,然后 apt-get install 就可以。随时随地可以 svn co 以前的项目找些代码,然后每次辛苦劳作之后 svn ci 的时候,就有无限的满足和成就感。

死了都要爱,爱死 Ubuntu.