2008-9
3
又一次错误的rm.
每次rm,我总是以我那飞快的指法而且是准确的在那么零点几个秒钟内就把命令打出去了。然后,总免不了有后悔的时候。
幸运的是,我每天的程序都只往前推进一点点。而且,每天关机睡觉之前,我总是要svn一下,并取一个新的版本号,才去睡觉。
不幸的是,这一天我改进了很多代码,并且将跟我机器相关的部分全部删除,存储部分从TokyoCabinet换到Mysql,将所有的代码加上了注释….就在我重新生成rdoc时 我一时头脑发晕就这么把整个目录删了。而且,就在我按下回车时我想起来了我输错命令了….
我原来打算着…等我完成了这一步,我就打成gem包 发布出来…
太Ft了。
想起我在某个公司的时候我们的运维同学用root帐户在开发机上cd到了根目录然后用了一个find 命令并将find到的文件全删除了。这本来是我教给他的,用以查找图片目录中有1个月以上没有被用到的文件然后删除之。可惜的是,我是让他在图片目录下运行,他却在根目录下运行了。于是乎,,,全挂了…连svn仓库也恢复不来了…
悲哀,
我心戚戚焉
RM 要慎用啊…
特别是带了 -r 之后
加-f 比较紧张一些
为什么将 TokyoCabinet换到Mysql,是什么类型的项目,我正在看TC的东西。
另外还看到你记录的我也很感兴趣的一个东西,spread
为什么你说:前一阵研究用spread来承载数据分发,做的报价系统很失败。是速度原因吗?
楼上的:
不是速度原因,是我perl太滥。
哦,我是用python来操作spread,还可以吧。感觉在合适的地方,spread应该很有用处的。
Tokyo Cabinet换成mysql是为什么呢?一般好像都是因为性能问题,mysql->tokyoCabine
我们项目组就准备测试一下这个TC,看看双机HA的形式,是否好用。