1、从svn clone出项目，加上-s参数以标记识别svn标准的目录分支结构，同时通过show-ignore设置git库的exclude属性：

1. git svn clone -s https://svn.xxx.com/svn/xxx
2. git svn show-ignore >> .git/info/exclude 

2、建立本地工作分支，开始工作：

1. git checkout -b work 

修改内容直接commit，加上-a开头以省略git add操作：

1. git commit -a 

3、提交回svn的过程：

1. git checkout master  
2. git merge work  
3. git svn rebase  
4. git svn dcommit 

在今天工作中，我提交回svn的方式是：

1. git checkout master  
2. git svn rebase  
3. git merge work 

结果svn rebase时在master分支上产生了一个新的node，这样merge时就不能快速合并，出现了冲突，修复后，在dcommit时出错，出现N个孤立节点。因为不熟悉，就checkout出work分支，进行了dcommit，然后重新生成一次git库。

今天解决了这个问题，参考以下网址：https://wiki.bnl.gov/dayabay/index.php?title=Synchronizing_Repositories。
以下重新描述一下问题和解决方法：
1、在执行git svn dcommit时，出现如下错误：
Committing to https://svn.xxx.com/svn/projects/trunk ...
提交时发生合并冲突: 您的文件或目录”test/functional/xxx_controller_test.rb“可能已经过时: The version resource does not correspond to the resource within the transaction.  Either the requested version resource is out of date (needs to be updated), or the requested version resource is newer than the transaction root (restart the commit). at /usr/bin/git-svn line 450
2、这时，重新执行以下步骤即可：

1. git svn fetch  
2. git svn rebase  
3. git svn dcommit 

但我在执行git svn rebase时，又出现冲突，这个时候，只需要手工合并掉冲突，并重新add一下：

1. git add . 

然后，再执行：

1. git rebase --continue

如果报告说没有修改内容，则换成执行：

1. git rebase --skip 

完成rebase过程，这时就可以git svn dcommit了。
这样，总算解决了svn历史冲突问题，不用象前面那样笨笨的重新git-svn clone.

今天发现pg连上30多接近40个连接的时候出现连接失败的状况。感觉上好像在pg的conf里看到一个connection是40，一翻果然如此，修改成100后启动可耻的失败鸟。。。

查看/var/log/messages大致意思是SEMMIN/SEMMNS不够了。好办，如下操作：

修改 /etc/sysctl.conf 增加以下指令
kern.ipc.shmmax=134217728
kern.ipc.shmall=32768
kern.ipc.semmap=256

修改 /boot/loader.conf 增加以下指令
kern.ipc.semmni=256
kern.ipc.semmns=512
kern.ipc.semmnu=256

修改/usr/local/psql/data/postgresql.conf
max_connections = 100

修改以后需要重启

一切安静了。。。正义狼不叫了，世界和平了。

cd /usr/ports/databases/postgresql84-server/
sudo make install clean

sudo emacs /etc/login.conf
---
postgres:\
        :lang=en_US.UTF-8:\
        :setenv=LC_COLLATE=C:\
        :tc=default:
---
and run `cap_mkdb /etc/login.conf'.
Then add 'postgresql_class="postgres"' to /etc/rc.conf.

To initialize the database, run

  sudo /usr/local/etc/rc.d/postgresql initdb

You can then start PostgreSQL by running:

  sudo /usr/local/etc/rc.d/postgresql start
To run PostgreSQL at startup, add
'postgresql_enable="YES"' to /etc/rc.conf

监听所有地址

sudo emacs /usr/local/pgsql/data/postgresql.conf
listen_addresses = '*'

允许某ip段连接

sudo emacs /usr/local/pgsql/data/pg_hba.conf
# my lan
host    all         all         192.168.64.0/22       md5

修改pgsql密码

su
su pgsql
psql -d postgres
alter user pgsql with password '******';

给某个db增加过程语言

createlang plpgsql yangchao

如果正在使用svn，打算换到git，又暂时不想放弃已有的svn代码库，可以选择git-svn。说一说我自己从svn到git的经验吧。

开始

安装最新版本的git，从git 1.5.3以后支持git-svn，git和svn的配合就要借助这个功能。

安装完毕后要做一些简单的配置。最直接的做法就是创建修改~/.gitconfig。下面是我的.gitconfig

[user]
        name = Robin Lu
        email = ---@gmail.com
[color]
        diff = auto
        status = auto
        branch = auto
[alias]
  st = status
  rb = svn rebase
  ci = commit -a
  co = checkout

[user]部分标示出使用者的身份，你提交的代码会自动引用这一身份信息。[color]设置命令输出的颜色。[alias]部分可以简化一些常用命令，比如在这里将git status简化为git st。

初始化代码库

首先用git-svn来初始化本地的代码库(repository)

git svn clone -s svn-repository-url

svn-repository-url部分使用svn代码库的url。如果要从trunk目录或者某个branch目录里check out，要把-s换成-T、-b等选项。具体参看man git-svn。这个命令时间比较长，因为需要同步所有的提交历史，还好只此一次，以后不会这么慢了。做完这一步，在本地就有了一个完整的代码库，包括所有commit的历史和log，已经可以开始用它来进行开发工作了。

不过，在开始开发之前，最好先做一次垃圾搜集：

git gc

它对代码库的信息进行垃圾搜集和压缩，最明显的作用就是减小磁盘占用空间。第一次做效果尤其明显。

你可以检查一下代码库的状态：

git status

现在应该在一个叫”master”的分支(branch)上。

用这个命令来显示出所有的分支(branch):

git branch -a

master前有一个*号，代表你现在所处的分支，另外还有一个分支叫trunk，它是一个远程分支(remote branch)，对应的是远程svn代码库。master实际上是trunk的一个本地分支。

接下来，需要配置忽略文件，让git忽略一些目录中不希望加入代码库的文件，类似svn propset svn:ignore。全局有效的忽略文件列表可以添加在./.git/info/exclude文件中。比如我需要忽略所有vi产生的swp文件：

.*.swp

对于和目录有关的忽略文件设置可以在该目录下创建.gitignore，然后加入需要忽略的内容，比如我希望忽略根目录下的log,tmp等目录，可以直接在根目录下的.gitignore中加入:

log
tmp

开发流程

可以开始工作了。用git后开始养成一个新习惯，就是工作前先创建新分支:

git checkout -b new_branch

-b后是分支名，创建的同时，你要转到了新分支上。尽量保持master上没有未提交到svn的commit，这样随时都可以很容易的产生一个干净的分支。

接下来你可以写代码，修改文件或者添加文件。如果想看看修改了什么，可以用：

git diff

如果对某个修改不满意，希望恢复原状，可以使用:

git checkout path/filename

相当于svn revert

git引入一个索引(index)的概念，提交前，需要把要提交的文件加入到git索引(index)中：

git add path/filename1
git add path/filename2
...

然后提交

git commit -m "提交感言"

每次commit都是提交索引(index)中的内容。

如果要一次提交所有修改过的文件，可以一次性添加，然后提交

git add .
git commit -m "提交感言"

如果只是修改，并没有添加新文件，可以直接用下面的命令:

git commit -a -m "提交感言"

将被修改文件加入索引并提交，一次完成全过程。

在修改加入所索引后，如果想看看索引内容中都所了什么修改，可以用：

git diff --cached

适合在提交前做最后的code review。

查看最近一次提交的内容，可以使用

git show

修改中随时查看当前代码库的状态：

git status

相当于svn status

删除和移动某个文件：

git rm file
git mv file newfile

提交到svn

在完成了几轮工作后，要将本地内容提交到远程svn中，可以先让当前分支和远程svn同步：

git svn rebase

然后将所有已经合并到master分支的本地修改提交到svn

git svn dcommit

如果在git svn rebase时发生代码冲突，需要先手动解决冲突，然后用git add将修改加入索引，然后继续rebase

git svn rebase --continue

缺点

最后说说这种工作方式的缺点。这个话题稍微复杂一点。

svn和git的工作原理毕竟不同，git对代码提交的非线性特性在svn中难以再现，如果使用了git-merge或者git-pull，再提交到svn，相关分支上的提交历史有可能无法体现在svn上。从svn的使用者的角度，无法辨别这是一个提交还是一次合并，所以在和svn协作过程中，尽量不要使用merge，或者说，尽量让代码库保持线性。

我的经验是，如果不在乎svn中是否反映出提交历史，使用merge也无妨。比如完成工作后，可以将工作分支合并到主分支中去：

git checkout master
git merge new_branch

先用checkout命令切换回master分支，然后将新分支中内容合并进来。然后在master分支上做git svn rebase和dcommit。从svn来看，这就是一个commit，new_branch上的提交历史在svn上体现不出来。(有例外情况，以后再讨论)。

还有一个解决办法是尽量保持git代码库的线性特征。比如在new_branch分支中，先和master做rebase，再合并到master分支中：

git rebase master
git checkout master
git merge new_branch

然后在master上做dcommit，就可以在svn代码库中看到完整的提交历史。

如果看到这已经有点头晕了，可以干脆不管它，就按照前面的做法，直接在你的工作分支里dcommit，等对非线性开发有一定了解再来看各种情况。

好了，基本上知道这些就可以干活了。

最近把版本管理系统换成git了，果然非常好用，难怪大家都在推荐。

首先不要有心理障碍，那些名词都是吓唬人的。所谓的“非线性开发”无非是指强大的branch和merge的能力，“分布式版本管理”就是说每人自己都有一套本地的repository，不存在一个集中的版本服务器。

给我带来的最直接的好处有：

1. 傻瓜都会的初始化，git init, git commit -a, 就完了。对于随便写两行代码就要放到SCM里的人来说，再合适不过。也可以拿git做备份系统，或者同步两台机器的文档，都很方便。
2. 绝大部分操作在本地完成，不用和集中SCM服务器交互，终于可以随时随地大胆地check in代码了。
3. branch管理容易多了，无论是建立新的branch，还是在branch之间切换都一条命令完成，不需要建立多余的目录。
4. branch之间merge时，不仅代码会merge在一起，check in历史也会保留，这点非常重要。

工具之所以好，除了方便好用，还在于它帮助并鼓励你做正确的事情。频繁check in是一件很好的事情，好处我不多说了，git就鼓励你频繁check in。branch也是一件好事情，我们大多很怕branch因为它太麻烦了，去掉这层心理包袱，branch可以让我们的开发工作很有条例。

还有一些实用的功能，比如bisect,用二分法来寻找regression，你以前手动做过这种事么？我做过。以后如果要做就不会怕了。还有stash，做hot fix非常方便。

如果正在用svn，劝服所有合作开发者使用git之前，可以先用git-svn，和svn整合得非常好。

分布式版本管理系统取代集中式版本管理系统，只是时间的问题了。

    前段时间去北京出差，看了烈火和上水轩的项目，最大的感触就是经验、人才的积累，个人的积累到项目组的积累到公司的积累，很强的个人能力，很好的团队氛围，加上完善的公司团队支撑，大个一路羡慕，其实我第一次看到也很羡慕，不过积累这种东西不是一个人能撑起来的。平常心就好。

    还是说下架构，这次去和左拉聊过之后，比较有感触，但是依然有不赞同的地方，他坚持单服构架，只是加入多线程设计使承载提升，上层倒是计划用一些类似无缝地图这样的技术，但是我对单服承载能力和容错能力依然表示怀疑。增加了出错几率和程序员调试时间，当然这些我对他是没底气争辩的，他完整的经历了两个项目，经验是无法比的。

    我依然坚持我的底层多线程，逻辑单线程架构，开发调试简单。单线程逻辑能力的不足我用多服来分散。就我的经验来看，这样对我目前的团队好处最大，因为服务端逻辑程序员都是新手，写多线程程序经验不足，经常死锁、漏锁。

    valgrind在内存泄露方面还是不太好用，也只能是能用，但是其他方面倒是有一些意想不到的收获，发现了几处逻辑BUG，比如我的服务端线程accept到新的socket后就创建一个线程收发包，但是停止时我先停了accept线程，不挂valgrind就没事，挂上就hang up在pthread_join位置上，郁闷很久，改了顺序就完全ok。

    针对内存泄露，我又找了一个很小的工具memcheck，效果出乎意料的好。我要的就是对malloc/realloc的内存检测是否free掉了。这个小工具也只有这个功能，在linux下面还能看到backtrace，不错不错。

    说到linux，不知道是我的错觉还是什么，新底层在linux下跑的貌似确实要好一些，不是指速度，那个是肉眼无法观察出来的，纯粹的感觉，调试过程中的输出、gdb给的反馈等等。怎么形容呢。感觉FreeBSD比较硬，更偏程序员多一些。linux就比较软，替服务器管理员考虑的就多一些。纯感觉。

金山有一套自己的服务端，单服务端，c++的，跑在CentOS上。代码很庞大。维护起来不是很方面，而且个人感觉使用了太多的c++的特性。

第一次重构服务端是刚来的时候，包括多服务端构架，多线程底层，因为时间紧，使用的是我上一个服务端的大体框架，上一套服务器使用c++/stlport/boost/asio，逻辑是简单了，但是问题也隐藏起来了，这次干脆使用纯c代码+libev。当底层搭建完成程序员开始工作后，我利用剩余时间重新考虑了一下服务端，首先被我放弃的是一开始就考虑上万人承载、无缝地图等等，把承载放在了比较合理的设计8k，实际5k一组上，经过和其他部门的沟通，在构架上也做了一些改动，避免了一处明显的瓶颈设计。

再次重构依然采用多服务端构架，做了简单的跨*nix平台，目前在FreeBSD7.2和CentOS5.2上开发，底层是多线程，逻辑单线程，客户端监听使用4个收，4个发来处理IO，服务端之间是一个连接一个线程，kqueue/epoll只针对客户端监听使用，监听使用一个，4个收包线程一个线程使用一个。

逻辑线程就一个，简单的从收到的包的队列里取出数据然后处理。

都是些轻车熟路的东西，写下来不到1000行代码，效果还需要压来测试。

在一次次重构中，真正感觉到了简单的美丽，现在的代码连libev都抛弃了，kqueue/epoll简单包装了一下，纯c的代码运用起来也渐渐得心应手，没有任何复杂的数据结构，感觉很好。

valgrind终于进行了重大升级，虽然features上提的是支持MacOS，但好歹和FreeBSD同源不是，3.5.0版本在FreeBSD上使用再也不需要mount /proc了，而且上个版本在FB7.2上根本用不成。这次表现的很好，虽然误报依然一大堆，但好歹有报不是。终于不在FB上写程序的时候提心吊胆了，以前可是根本就没泄露检测工具。反倒是CentOS上编译valgrind失败，好像是一个define的问题，没去管它。

当个项目总监，特别是比较大项目的管理者还是很累的，不过我觉得做管理要有所依，服务端编程我不会放下，再忙每天都要抽出时间来写几段代码，其实管理很简单，我的风格不喜欢搞太多事情，懒，但是做管理这样是不够的，缺乏强沟通、强推动。总觉得团队少了最核心的一点什么。努力！

别鄙视我，国情嘛。

Mark一下，免得30天后又忘了。改天有空研究一下多Agent的效率。

IncrediBuild是一个很强的分布式编译工具，可以明显缩短大型项目编译时间，但是价格不菲。对于我这样的穷人来说，只能使用试用版。试用期限是30天，30天到了即使删掉再安装仍然不能使用。给Xoreax写信申请延长试用期限，也没给答复，估计针对个人他们根本就不让延长试用。

令人郁闷的是，网上能找到的所有破解都是无效的。即使界面显示已经破解，但是时间一到，功能根本不正常。根本不会把编译任务分发给别人，只能本机编译了。

IncrediBuild 2.40的License有2个文件CoordLicense.dat和AgentLicense.dat，分别位于Coordinator和Agent安装目录下，这两个文件都是RSA数字签名过的，除非修改.exe文件中的解密密钥，否则没法伪造License文件。但既然网上能找到的破解都无法正常使用，所以肯定不容易搞定。对于3.20应该也大同小异。

IncrediBuild在第一次运行的时候会向注册表中写入软件到期的时间。

2.40: HKCR\Interface\{E9B0227F-437C-4F7A-86D9-2676B83F359F}\ProxyStubClsid32 = {M1-M2-M3-T1-T2}

3.20: HKCR\Interface\{B7348B5D-B65D-4BF5-AF63-A3135249ACA7}\ProxyStubClsid32 = {M1-M2-M3-T1-T2}

卸载软件的时候并不会卸载这个注册表项，所以重新安装仍然不能使用。最简单的办法是卸载软件后手动删除这个注册表项，然后重新安装，就又可以继续试用。还有一种办法就是，我们定期更新上面这个注册表项的值，把时间往后推移。还好该软件时间算法并不复杂，很容易算出来。

比如说到期时间是2008.5.30日23:59:59，可以写两行简单的代码：

COleDateTime DateTime(2008, 5, 30, 23, 59, 59);

DATE Date = (DATE)DateTime;

此时Date的值是39598.999988425923 (0x37BA E7FFDF55E340)

T1：37BA

T2：E7FFDF55E340

M1 = 37 * BA * E7 * FF = 23EAEB06

M2 = DF * 55 = 4A0B

M3 = E3 * 40 = 38C0

这样我们就可以把注册表中上述键值改为：{23EAEB06-4A0B-38C0-37BA-E7FFDF55E340}

这样，软件到了2008.5.31 00:00:00才会过期。

这个年龄了。眼镜的度数应该不会有太大变化了。

记下来吧。免得每次都要找借口去眼镜店眼光

R –3.75 –2.00 X165

L –5.00 –2.00 X15

瞳距68

好记性不如烂笔头

systat基本上是FreeBSD中最功能最多的系统监视命令，显示CPU、I/O、内存、虚拟内存、mbufs、磁盘IO、网络状态等信息等。

命令：

systat [-display] [refresh-interval]

其中 display 为我们所要显示的信息项目，我们也可以在进入 systat 后通过输入“:display”变更显示项目，refresh-interval 参数是需要多长时间采样一次系统数据输出到屏幕，单位是秒。

实例：# systat -vmstat 1

命令解释：显示CPU、I/O、内存、虚拟内存、mbufs、磁盘IO、网络状态等信息。信息采样刷新时间为1秒。

以下为可用的 display 参数：

pigs 显示目前系统中使用 CPU 最多的行程名称。如果所有行程的 CPU 使用量未满 100%，则多出来的部份显示为 IDLE。
icmp 统计目前 ICMP 封包的进出情形。
icmp6 显示 IPv6 的 ICMP 封包进出情形。
ip 显示 IP 层的封包统计及 UDP 封包信息。
ip6 和 IP 一样，但只显示 IPv6 的封包。
tcp 显示 TCP 的封包统计。
iostat 显示 I/O 状况统计，并分类为各种模式显示。
swap 显示目前各个储存空间上的虚拟内存的使用情形。
mbufs 显示 mbufs 被使用的状态。
vmstat 这是我们最常用的显示模式，它显示了最多的信息，包含 I/O、虚拟内存、mbufs、网络等信息。
netstat 显示网络的使用情形。
ifstat 显示各个网络适配卡的使用情形。

==================================================

最快的FreeBSD升级办法：

The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 7.0-RELEASE, 7.1-RELEASE, 7.2-BETA, 7.2-RC1, or 7.2-RC2 can upgrade as follows:

# freebsd-update upgrade -r 7.2-RELEASE

During this process, FreeBSD Update may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly.

# freebsd-update install

The system must be rebooted with the newly installed kernel before continuing.

# shutdown -r now

After rebooting, freebsd-update needs to be run again to install the new userland components, and the system needs to be rebooted again:

# freebsd-update install
# shutdown -r now

Users of earlier FreeBSD releases (FreeBSD 6.x) can also use freebsd-update to upgrade to FreeBSD 7.2, but will be prompted to rebuild all third-party applications (e.g., anything installed from the ports tree) after the second invocation of "freebsd-update install", in order to handle differences in the system libraries between FreeBSD 6.x and FreeBSD 7.x.

==================================================

添加用户组：

pw group add coder

添加新用户：

adduser