Mysql Replication 最简单配置

Google 一下Mysql Replication可以找到相关配置说明满地都是,作为双机热备方案很多时候需要用到,但是稍微看下这些资料发现都是乱七八糟的,所以果断去读MySQL 5.1 Reference Manual: 16.1.1. How to Set Up Replication。资料很长,不过最后总结的配置其实非常简单。

配置

1. In Master (例子IP 10.6.7.7)

my.cnf 添加这两行:

[mysqld]
log-bin=mysql-bin
server-id=1

终端中运行:

1
2
3
mysqldump -uroot -p --all-databases --master-data | gzip -9 -c > dbdump.db.gz
scp dbdump.db.gz user@10.6.7.8:~
echo "CREATE USER 'repl'@'%' IDENTIFIED BY 'slavepass'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';" | mysql -uroot -p

2. In Slave (例子IP 10.6.7.8)

my.cnf 添加和Master不同的ID:

[mysqld]
server-id=1001

终端中运行:

1
2
3
MASTER_IP=10.6.7.7
 
(echo "SLAVE STOP; CHANGE MASTER TO MASTER_HOST='$MASTER_IP', MASTER_USER='repl', MASTER_PASSWORD='slavepass';"; zcat dbdump.db.gz;echo "SLAVE START;") | mysql -uroot -p

OK, 收工。

验证

要验证同步,在Master执行:CREATE DATABASE test_repl;, 在Slave执行 SHOW DATABASES;,可以看到test_repl同步完成,在Master执行:DROP DATABASE test_repl;,Slave的也相应消失。

完整的启动LOG /var/log/mysql/error.log大致如下,可看到replication线程启动正常。

120424 16:34:51 [Note] Plugin 'FEDERATED' is disabled.
120424 16:34:52  InnoDB: Initializing buffer pool, size = 8.0M
120424 16:34:52  InnoDB: Completed initialization of buffer pool
120424 16:34:52  InnoDB: Started; log sequence number 0 1174665
120424 16:34:52 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin.000001' at position 1060, relay log './ub1110-relay-bin.000024' position: 251
120424 16:34:52 [Note] Event Scheduler: Loaded 0 events
120424 16:34:52 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.1.61-0ubuntu0.11.10.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
120424 16:34:52 [Note] Slave I/O thread: connected to master 'repl@172.28.16.82:3306',replication started in log 'mysql-bin.000001' at position 1060

收尾

Slave的/var/log/mysql/error.log可能会看到一个warnning

120423 18:01:41 [Warning] Neither --relay-log nor --relay-log-index were used; so replication may break when this MySQL server acts as a slave and has his host name changed!! Please use '--relay-log=XXXXX-relay-bin' to avoid this problem.

如它所说,把这句加入到my.cnf[mysqld]即可。

日常维护

如果数据库操作频繁,binlog消耗的磁盘空间挺大的,设置Master的expire_logs_days可以控制存储binlog的文件个数。

如果留下了大堆binlog需要清理,可以执行这句清理7天前的binlog:

1
mysql -uroot -p -e "PURGE MASTER LOGS BEFORE DATE_SUB( NOW(), INTERVAL 7 DAY);"
文章分类 Mysql 标签: ,

Midware beaker using Google App Engine Memcache API as backend

What

Beaker is a library for caching and sessions for use with web applications and stand-alone Python scripts and applications. — Beaker Offcial Document

Why

I recently writting a small app running on Google App Engine, Beaker is the ideal midware working together with light weight python web frameworks, eg bottle, web.py, to handle session things.

The GAE provides a bunch of external services, which are extremely convinent for building apps. Beaker supports using google’s Datastore api as backend, but operations over the Datastore is expensive (actually still free to me, hah), it would be more delightful to use the (currently) unlimited memcache service.

Beaker supports memcached backend, too, but only to those ordinary APIs, like pylibmc, cmemcache which connect to specified addresses as a client. The GAE memcache however, with exactly same interfaces, but no need to connect to somewhere before operating data. So, it needs some work over Beaker.

Patch

  1. Download this googlememcache.py ext module and save as beaker/ext/googlememcache.py
  2. Apply the following patch in the beaker directory. (Minor modification over cache.py)
diff -r 0bf25d5b4287 beaker/cache.py
--- a/beaker/cache.py   Mon Mar 12 14:19:57 2012 -0700
+++ b/beaker/cache.py   Wed Apr 11 17:29:30 2012 +0800
@@ -18,6 +18,7 @@
 import beaker.ext.database as database
 import beaker.ext.sqla as sqla
 import beaker.ext.google as google
+import beaker.ext.googlememcache as googlememcache
 
 # Initialize the cache region dict
 cache_regions = {}
@@ -115,6 +116,7 @@
           'ext:database':database.DatabaseNamespaceManager,
           'ext:sqla': sqla.SqlaNamespaceManager,
           'ext:google': google.GoogleNamespaceManager,
+          'ext:googlememcache': googlememcache.GoogleMemcacheNamespaceManager,
           })

Usage

Nothing much different from using the original ext:google

1
2
3
4
5
6
session_opts = {
    'session.cookie_expires': True,
    'session.type': 'ext:googlememcache',
}
 
app = SessionMiddleware(orig_app, session_opts)

Upstream

I submitted this patch to the Beaker offcial, not sure if they will adopt it as a new feature in the later releases.

文章分类 web技术 标签: , , , ,

一次本博客的性能故障排查

无关背景

Ubuntu 10.04 这个版本已经服役两年,虽说是LTS,但最近起发现已经有点力不从心,主要是ppa上一些比较重要的库,如PHP 5.3,ningx的团队已经停止维护,uwsgi则总是落后半年的样子。很大一个原因是这些包在新版的Ubuntu里面已经有官方维护,ppa的第三方维护会缺乏跟进。所以在一定意义上,可以宣布Ubuntu 10.04死亡了。

但Ubuntu的包维护策略就是那样,要么自己维护所有用到的包,要么每隔一段时间就跟着官方一次大升级。觉得不爽就干脆把VPS的系统也改成Archlinux。

现象

一番大迁移后所有的东西都正常上线,但直到一个多星期后的昨天晚上才注意到博客的性能问题。 因为博客那里有nginx直接读取静态的缓冲机制,所以动态执行非常慢之前都没留意到。

把缓冲关闭就非常明显了,任何一次点击的页面都要10秒才能打开。

排查

引起应用缓慢的因素是非常多的,概括来说有两种:IO慢运算慢

运算慢是不大常见的,虽说PHP性能一直受到诟病。但如果是这个问题是很明显的,top里面php的子进程会占满CPU,高居不下。此前排查过一个drupal的站点,是因为前端模板的组件方式存在循环引用,用profile过程看,正则替换的regrex函数占了绝大多的CPU时间。

在SSH看到,打开页面的10秒内php-fpm的子进程基本没占CPU,排除这个可能。

IO慢就复杂了,每个组件都有IO,得先确定IO的范围。

首先想到是数据库Mysql,arch的包太新,有bug?linode主机的磁盘快挂了,磁盘很慢?这些都不好判断,确定这些得借助工具。

Profiling是追踪一个应用的运行流程,记录所有的函数调用栈、记录调用时间的过程,是追查性能问题的最佳帮手。Python里面是有个repoze.profile的wsgi中间件很方便进行排查,但我没做过完整PHP开发,就暂时不大清楚有什么方便的profile方案 (以前弄过早忘了),但google一下还是有很多方案的 ,不过我首先想起newrelic的应用监控系统就提供了这个功能。

Newrelic针对WEB应用和服务器监控服务,其中的服务器监控是免费的,但对应用的监控只有14天试用;所以我赶紧重新申请个帐号,用来监控一下wordpress。安装好监控模块后,超过2s的响应会在他们的Transaction traces记录下来。

newrelic-profile-apt-blog.png

图表数据可以排除数据库问题,几十个数据库的操作都是在ms级别完成,而在apt-blog.net的耗时花了10秒。其实我一开始对这个报告也没看懂,newrelic的直观性还有待提高,其实在这里出现域名的意思是有网络请求,比如askimet的评论、插件的更新等都要和外部请求,这里就会出现域名。

而现在出现了自己博客的域名,那问题就是,程序里面某个地方需要请求自己的域名,可能是检查状态的操作,被卡住了,直到超时才返回。

本机程序访问不到本机,基本确定是iptables规则出问题了,在filter表的最后插入这样一句:

-A INPUT -j LOG

iptables的规则一般是,除非明文允许,否则拒绝,所以经过一系列的规则后如果还没有没ACCEPT的,在最后的都是被DROP了,把这句放最后可以看到究竟是什么包被DROP了。

查看/var/log/everything.log看到这样的记录:

Mar 31 03:17:32 (none) kernel: [17554800.765033] IN=lo OUT= MAC=00:00:00:00:00:0 0:00:00:00:00:00:00:08:00 SRC=106.187.36.50 DST=106.187.36.50 LEN=60 TOS=0x00 PR EC=0x00 TTL=64 ID=31529 DF PROTO=TCP SPT=45594 DPT=80 WINDOW=32792 RES=0x00 SYN URGP=0

这里透露了重要信息:IN=lo SRC=106.187.36.50 DST=106.187.36.50,PHP确实有访问本地网络,送了给lo网卡,SRC和DST都是本地的公网地址。赶紧检查iptables的规则,果然没了对lo设备的允许规则。一般配置机器我都是用记录在自己的Wiki的iptables那套规则的。关于lo的这几句可能一时没仔细想其作用,迁移系统那天脑抽手贱就删掉了。

加入允许lo设备的这句:

-A INPUT -i lo -j ACCEPT

至此,问题解决。

文章分类 Networking, Unix/Linux, 运维技术

OpenVPN over HTTP 突破Layer 7 QoS的宽带网速限制

Why

我家里用的是一家三线的便宜小区宽带,标称有几个M的带宽,虽说有些资源确实能达到这个速度,但发现直连VPN的速度从来都没上去过,大概30k/s,不难猜测到,ISP在链路上做了手脚,即所谓的Layer 7 Priority QoS。因为入线是100M进宅然后PPPoE,不像ADSL那样直接物理链路就限制了连接速度,在链路层做QoS也很合理。平时HTTP打开网页、下载到合适链路的话很容易达到满速,而OpenVPN的TCP/UDP包估计就被当成P2P流量被限制了,所以网速一点都不给力。

用OpenVPN科学上网是最稳定最灵活的方式了,它基于udp/tcp的协议,比pptp、l2tp等直接跑IP包的开销虽说大一点,但好处就是容易把数据流重新封装,避开链路的关卡。显然它也支持HTTP代理,所以把OpenVPN变成HTTP协议,就可以在家里跑上满速的VPN。

How

OpenVPN要过HTTP代理,只能用TCP协议,这个需要服务端和客户端都要稍作修改。

Polipo as Tunnel Proxy

首先在VPS上安装一个http proxy,我选择polipo,比较轻量级。

apt-get install polipo

配置也是很简单的,编辑/etc/polipo/config,原来的配置文件基本全都是注释,直接在文件底部加上:

proxyAddress = "0.0.0.0"
proxyPort = 8128
authCredentials = "user:password3.141592654"
tunnelAllowedPorts = 1194
  • polipo默认只监听本地的127.0.0.1,要拿来做服务就要监听外网
  • polipo默认监听8123,为了不让扫代理的盯上,自己随便写个端口
  • 加上http basic验证,这个密码不要紧,后面让openvpn自动应答
  • 允许管道模式连接openvpn的1194端口

OpenVPN

Server

服务端倒是不需要很多配置,确定是tcp模式监听连接(我是多开一个openvpn server,子网错开,个人喜欢吧)

Client

客户端就要指定使用代理的方式:

remote 127.0.0.1 1194
http-proxy YOUR.VPS.IP.HERE.com 8128 pw.txt
http-proxy-retry

这个pw.txt是上述的HTTP的认证信息,用户名密码各一行。

现在连接OpenVPN,可以看到连接过程的Log有这么几句,基本就确定OpenVPN over HTTP成功了!

Sun Mar  4 19:12:58 2012 Attempting to establish TCP connection with 199.101.103.107:8192 [nonblock]
Sun Mar  4 19:12:59 2012 TCP connection established with [IPADDR]:8128
Sun Mar  4 19:12:59 2012 Send to HTTP proxy: 'CONNECT 127.0.0.1:1194 HTTP/1.0'
Sun Mar  4 19:12:59 2012 Attempting Basic Proxy-Authorization
Sun Mar  4 19:13:00 2012 HTTP proxy returned: 'HTTP/1.1 200 Tunnel established'

Related

最后透露一下我的科学上网环境是在跑OpenWRT的路由器上跑VPN,然后配合chnroute的路由表,当然dnsmasq也经过配置负责把国内常用域名的解释交给国内的114.114.114.114服务器,这样基本一回家手机kindle电脑等全都是翻墙环境,而且速度非常良好。

Reference

文章分类 Networking, Unix/Linux 标签: , , ,

x11vnc – 远程工作站桌面

Gnome Desktop Environment的VNC服务开启很容易,仅需点开Desktop Sharing,打个勾就完了。(运行vino-preferences的界面)

vino-preferences Gnome默认的VNC配置界面

但是有时候某台工作站没有打开这个VNC服务,只有SSH,但是又必须通过桌面来操作,这时候自带的vino server就好像不容易跑起来。

x11vnc这个小工具就可以派上用场,它对当前的x11 session建立VNC服务,很简单直接运行x11vnc,就等你连接5900端口了。当然,如果一定要指定一个session,有个-display参数可以指定,或者看看x11vnc --help,好长好长~~~

文章分类 Unix/Linux 标签: , ,

uWSGI的几个使用技巧

uWSGI基本上是python做web服务的不二选择了,但似乎项目的开发者比较热衷于其新功能开发,对其使用文档还是相当缺乏的。

安装:

Ubuntu

添加ppa,安装。 目前只有Lucid, Maverick, Natty几个版本还需要添加,以后版本都在官方原,直接apt-get install即可。

1
2
3
add-apt-repository ppa:uwsgi/release
apt-get update
apt-get install uwsgi-python

Debian

目前Debian sid已经收录了uwsgi,一般服务器安装的testing/stable,只能自己修改apt的配置,从sid里面port过来。

注意:以下操作可能毁掉您的整个debian包系统。以下命令仅在Debian wheezy,即目前的testing运行测试安装过,如果你的是squeeze,自己修改01all那里 Pin: release a=squeeze 一行,但不保证能够正常运行。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
echo "deb http://ftp.tw.debian.org/debian sid main non-free contrib" >> /etc/apt/sources.list
cat > /etc/apt/preferences.d/01all << EOF
Package: *
Pin: release a=testing
Pin-Priority: 1000
EOF
 
cat > /etc/apt/preferences.d/02uwsgi << EOF
Package: uwsgi
Pin: release a=sid
Pin-Priority: 1010
EOF
 
apt-get update
apt-get install uwsgi uwsgi-core uwsgi-plugin-python

Centos, RHEL, Fedora, …

You’re on your own, linux user.

配置

常见配置文件:

1
2
3
4
5
6
7
8
9
10
11
cat > /etc/uwsgi/apps-enabled/test.ini << EOF
[uwsgi]
chmod-socket = 666
limit-as = 256
processes = 6
max-request = 2000
memory-report = true
enable-threads = true
virtualenv = /somewhere/to/your/virtualenv
wsgi-file = /home/somewhere/app.py
EOF

用ini方式的配置是比xml的容易写多了。具体配置说明请看Doc

默认的sock文件在/var/run/uwsgi/test/socket

配合nginx使用的配置文件:

1
2
3
4
5
6
7
8
9
10
cat > /etc/nginx/sites-enabled/test << EOF
server {
        listen   80;
        server_name host.domain.com;
        location / {
                include uwsgi_params;
                uwsgi_pass unix:///var/run/uwsgi/test/socket;
        }
}
EOF

切换Python版本

系统中可能安装有多个版本的Python,又或者同个系统里面有的app跑python3, 有的跑python2.6 stackless, 有的跑python2.7…

uwsgi 是通过plugin的方式加载不同的python解析器的,debian的uwsgi-plugin-python包里面提供了python26_plugin.so, python27_plugin.so, 不过uwsgi如果在app配置里面没有plugins参数指定使用哪个时候,会尝试加载/usr/lib/uwsgi/plugins/python_plugin.so,这个文件在debian下是个链接文件,可以运行update-alternatives --config uwsgi-plugin-python命令来修改这个默认版本。

源里面没有提供stackless python的plugin,只能自己编译了,还好非常简单:

/path/to/your/stackless/python uwsgiconfig.py --plugin plugins/stackless

然后把生成的python_stackless.so放到/usr/lib/uwsgi/plugins 就能被uwsgi加载了。

其他plugin的编译基本都这样,看源代码里面的plugins目录。

代码

使用uwsgi运行代码的时候,可以import uwsgi模块,和uwsgi进行一定的交互。

uwsgi 的源代码包当中有个uwsgidecorators.py,提供了多数的uwsgi接口,描述文档在此。以下是几个典型应用。

自动重载

好一些web框架都有检测修改了源文件就自动重新加载的功能,但是在uwsgi里面这个方法是不好用了。

Django

加入以下代码:

1
2
3
4
5
6
7
8
import uwsgi
from uwsgidecorators import timer
from django.utils import autoreload
 
@timer(3)
def change_code_gracefull_reload(sig):
    if autoreload.code_changed():
        uwsgi.reload()

Bottle

Bottle 的reload是它内置基础web服务器的功能,在uwsgi里面只能自己写代码监控。

想要简单很难做到完美:

1
2
3
4
5
6
7
from uwsgidecorators import filemon
 
filemon('/tmp/foo')(uwsgi.reload)
filemon('/tmp/foo2')(uwsgi.reload)
filemon('/tmp/foo3')(uwsgi.reload)
filemon('/tmp/foo4')(uwsgi.reload)
filemon('/tmp/foo5')(uwsgi.reload)

于是这些文件出现修改的时候,就自动reload。其实你可以自己加入调用uwsgi.reload()的响应。

pylons, web.py, cherrypy ..

程序员自己研究去。

threading

原来使用内置线程做的异步程序会发现在uwsgi,里面的线程好像都没启动了、数据库没有连接了……原因是uwsgi加载了代码后,fork出多个子进程,子进程里面的线程如果没有被再度激活,是不工作的。

有两个方法,一是在这个app的配置里面加上:

lazy = true

这样代码会在子进程fork了之后才开始加载。

二是使用uwsgi模块的api,uwsgidecorators 里面有相应的装饰器,这样uwsgi会在fork之后自动调用你要重新启动的线程。

1
2
3
4
5
6
7
8
9
10
11
12
13
from uwsgidecorators import postfork
 
@postfork
def reconnect_to_db():
    myfoodb.connect()
 
@postfork
def restart_threads():
    global thread1, thread2
    thread1 = MyThread1()
    thread1.start()
    thread2 = MyThread2()
    thread2.start()

监控

虽然uwsgi 默认带了SNMP功能,可以给外部监控其运行情况,但uwsgi的源码包里面带了个uwsgistatus.py文件,里面简单的提供了读取uwsgi模块的属性形成的报告。 可以把里面的代码copy到app项目里面,作为一个简单的监控数据。

2011-11-24_19-04-14.png

Reference

以上部分代码取自uWSGI Wiki页面

文章分类 Python, web技术 标签: ,

Python多重继承的异构构造器

What

在Python里面,如果你使用上Qt,SQLAlchemy,Twisted之类各种大型类库时候,有时候多重继承Multiple Inheritance是个简单的解决方法,但是多重继承的复杂性总容易造成误解和疑惑。

一般“常识”说,使用super访问父类的属性/方法,这种说法在多重继承里面是不成立的,多重继承的类并没有父类的概念(There is no superclass in a MI world)。类似的博客在过去几年被人写了无数遍了,因为过去版本里面python官方文档对super的解释非常有限而且有误导解释,直到2.6以后的文档,才详细说明了super在单继承和多继承的两种不同工作方式。当时苦逼的程序员甚至不得不去翻看Python源码才搞清楚是什么回事。以致几年来很多人对python的多重继承保持怀疑态度。

Python多重继承使用Method Resolution Order的动态算法来解决一个方法名的调用顺序,mro其实说来简单,就是一个深度优先的继承列表,很易理解,但随之来的是遇到互不相同的构造器__init__参数的问题。

Codepad运行结果:http://codepad.org/qQNiMzBl

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
class A(object):
    def __init__(self, arg1):
        print "init func in A, with arg1 '%s'" % arg1
        super(A, self).__init__()
 
class B(object):
    def __init__(self, arg1, arg2):
        print "init func in B, with arg1'%s', arg2 '%s'" % (arg1, arg2)
        super(B, self).__init__(arg1)
 
class C(B, A):
    def __init__(self, arg1, arg2):
        print "init func in C, with arg1'%s', arg2 '%s'" % (arg1, arg2)
        super(C, self).__init__(arg1, arg2)
        print C.__mro__
 
c = C("C's arg1", "C's arg2")

执行结果:

init func in C, with arg1'C's arg1', arg2 'C's arg2'
init func in B, with arg1'C's arg1', arg2 'C's arg2'
init func in A, with arg1 'C's arg1'
(<class '__main__.C'>, <class '__main__.B'>, <class '__main__.A'>, <type 'object'>)

可见几个类的构造器的执行顺序正是mro列表的顺序。重点是多重继承的各个类的构造器__init__之所以能够执行,是因为每个构造器里面都有一句super(),这个super完成mro列表中下一个类的构造器的调用

这个事实听起来似乎很自然,但看代码,B的构造器还得必须知道A的构造器的参数?B需要知道自己将会被C同时继承A,并且调用A的构造?!!很荒谬,但不幸的这是mro的特点。代码是可以这么写,但不应该,为另一个不知道什么时候会被一起继承的类特地地写代码,跟面对对象设计的解耦原则相违背。

How

在mro方式的基础上,这个问题是不可能有效解决的,只能避免。概括起来大概有这么 两种方式。

1.使用传统类的方式,显式调用被继承类的构造器,避开super的mro自动化工作。

Codepad 看运行效果: http://codepad.org/XCVdKCPm

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
class A(object):
    def __init__(self, arg1):
        print "init func in A, with arg1 '%s'" % arg1
 
class B(object):
    def __init__(self, arg1, arg2):
        print "init func in B, with arg1'%s', arg2 '%s'" % (arg1, arg2)
 
class C(A, B):
    def __init__(self, arg1, arg2):
        print "init func in C, with arg1'%s', arg2 '%s'" % (arg1, arg2)
        #super(C, self).__init__(arg1) #这两行
        A.__init__(self, arg1)       #等价
        B.__init__(self, arg1, arg2)
        print C.__mro__
 
c = C("C's arg1", "C's arg2")

注意 C继承A,B的顺序已经改变。

要排除一个容易产生的误解。Python文档里面的super有个很显著的Note:super() only works for new-style classes. super只适用于新类。但新类并不必须使用super

直接调用被继承类__init__作为unbound方法调用,需要指定一个实例,如self作为参数,依次调用各个被继承类。缺点是若果这几个被继承类也在构造方法里面使用这样调用了同一个上级被继承类,会出现“爷爷类”的构造方法被调用多次的情况。

如果一定使用super,要注意继承列表的顺序。super(TYPE, self).method调用的是mro列表中第一个,也即继承列表第一个类的方法。

PyQt里面的类内部一般(未细究)都使用__init__的方式来初始化代码,因而很多PyQt的例子代码都是使用QtGui.QMainWindow.__init__(self)这样的代码来初始化。当然在单继承时候和super的写法是等价的,但最好使用统一的原则:

一个简单好记的原则:

  • 如果”被继承类”都使用__init__,”继承类”就使用__init__来初始化;
  • 如果”被继承类”都使用super,”继承类”就使用super来初始化;

2.使用Composition / Association Pattern的设计模式(即’Is-A’转换成’Has-A’)来实现相同功能,避免多重继承。

这个方法听起来未免有点让人不快(破坏了原有设计思维),但实际上很可能这是更好的方式,更清晰的代码,尤其是要继承的类里面混合了使用super__init__两种初始化方式的时候。

Reference

文章分类 Python 标签: , , ,

HG的秘密武器 — Mercurial Queue

Why

惯用版本管理的coder会发现,经常整理代码时候,要提交出一个完美的版本库还真不容易,有时候不仔细连语法错误的版本都commit进去了仓库,如果以洁癖的眼光看,这是不可容忍的:

  • 仓库每个版本均可无错编译
  • 每次提交的目的简单明了,不应多个不相关修改合在同一次commit
  • 提交说明可以简单明了和修改了的代码联系起来

Mercurial 默认配置情况下不易做到这个,相比起git,hg没有git的index概念,一次commit可以经过多次记录才确认成一个版本。但是hg自带了个插件Mercurial Queue,功能上可比git更胜一筹。

考虑这么一个情况,在做新功能探索的代码,尝试到有一步成果了,但后面出现几种方案需要测试,暂时还不知道用那个。如果把目前的版本提交,又不成熟,不足以作为一个版本。有mq的话,直接qrefresh记录当前的修改,再随便折腾代码,不爽直接revert,这个记录还没有成为commit,直到最后觉得满意了,qfinish my_perfect_patch,才最后提交成一个版本。

另外一个情况,在开发新功能时候,代码改了一堆了,突然rp爆发,一眼就发现了以前版本留下的一个很隐藏的bug。

没有mq的话,你有3种方式处理:

  • 记住!好大的BUG!完成这次功能,提交后再Fix掉! (然后忘了)
  • 把这行代码的位置写到paster贴显示器上;
  • 马上修正bug,继续写代码,最后提交版本的时候写: added xxxxxxx; fixed xxxxxx;

都不怎么靠谱吧,使用mq的话,这可不是什么问题:

  1. 暂停coding,记录下目前的进展,qrefreshqpop出当前已有修改。
  2. 创建一个新的patch,qnew fix_xxx
  3. fix bug,qrefreshqfinish fix_xxx。这时仓库里面已经有一个修好bug的版本了。
  4. qpush回到刚才的状态,继续coding新功能。

“提交 commit”是版本管理里面一系列不可修改的历史,一旦提交后就不能修改他们的状态和顺序。mq里面的queue虽然也是历史的部分,但还没有永久成型,可以任意改变,直到成熟,可有效提高仓库中的版本质量。

不过使用mq后这个情况也有点改变,配置好mq后会有了一个邪恶的strip命令,可以从提交历史当中直接删除一个commit。虽然这显然是不尊重历史的,不过作为灵活特性,git也有这样的功能,毕竟特殊时候可以避免信息泄漏等事情。

How

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
28
29
30
31
#几乎所有资料都叫你先运行hg qinit,不过这是过时的命令,所有mq的命令都会默认创建好patch环境
 
# 往常地,在版本目录里面改代码,coding ...
 
# 好了差不多了,我要记录下我刚才这一次优秀的改进,可能还不够完美,但绝对是空前绝后的。
 
hg qnew -m "fabulous improvement" wonderful-2011 # 创建了名为`wonderful-2011` 的一个patch,包括了刚才的所有改动;
 
# 现在hg diff是没有改变输出的;hg qdiff倒有。
 
# 继续浏览了一次刚才的美妙代码,哎呀有好几处暇疵什么的,啊有几个只有半边括号的,好吧已经改善了,已经运行过,跑的很好
 
hg qrefresh  # 现在改善后的代码也记录完成了。
 
# 哎呀发现了个大bug,这个bug应该在之前的代码上就完成修改的
 
hg qpop #把刚才的修改暂时去掉
 
hg qnew -m "fix bug" fix-bug # 新建一个patch
 
# fix bug fix bug fix bug
 
hg qrefresh #记录fix bug的修改
 
hg qfinish fix-bug #把fix-bug提交进去
 
hg qpush # 回到刚才的,wonderful-2011
 
# 继续coding
 
hg qfinish -a # 完美了,把所有patch都commit到仓库。收工。

Advanced

Mercurial Queue 名字虽然叫queue,但里面主要都是一个个patch栈的形式,对每一次patch进行pop/push那样的操作,每个栈称为一个queue,使用qqueue命令可以创建多个queue,并在它们之间自由切换,各个queue内的patch相互独立,自由度非常高(比git还灵活)。

每个队列里面的一系列patch是按先后顺序排列的,要应用的话必须按顺序。但是qguard命令可以让你选择性地应用相应的guard下某些补丁来测试 (orz) 。

其实mq的工作是基于项目目录下.hg/patches里面的内容,里面记录着你所有的patch。细细一想,其实每次qrefresh就是覆盖掉之前的修改,如果不小心改错了怎么办啊!!! 不怕,还有管理版本管理目录的版本管理 (误!),给patches目录建个仓库就是了嘛,mq已经为你设计好了,执行hg init --mq,即可,之后每次qrefresh,都可以qcommit一下让patches里面的仓库记录你的修改。

不过这样的特性太高级了,让我处理那么复杂的补丁机制估计会疯掉的,真有兴趣的同学情参考下列文档。

Reference

初级资料

高级资料

重点推荐A Git User’s Guide to Mercurial Queues,文章比较图文并茂解释mq里面的概念,而且和git特性做了优缺点对比。

文章分类 版本管理 标签: , ,