1、從svn clone出項目，加上-s參數(shù)以標(biāo)記識別svn標(biāo)準(zhǔn)的目錄分支結(jié)構(gòu)，同時通過show-ignore設(shè)置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 

修改內(nèi)容直接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 

結(jié)果svn rebase時在master分支上產(chǎn)生了一個新的node，這樣merge時就不能快速合并，出現(xiàn)了沖突，修復(fù)后，在dcommit時出錯，出現(xiàn)N個孤立節(jié)點(diǎn)。因為不熟悉，就checkout出work分支，進(jìn)行了dcommit，然后重新生成一次git庫。

今天解決了這個問題，參考以下網(wǎng)址：https://wiki.bnl.gov/dayabay/index.php?title=Synchronizing_Repositories。
以下重新描述一下問題和解決方法：
1、在執(zhí)行g(shù)it svn dcommit時，出現(xiàn)如下錯誤：
Committing to https://svn.xxx.com/svn/projects/trunk ...
提交時發(fā)生合并沖突: 您的文件或目錄”test/functional/xxx_controller_test.rb“可能已經(jīng)過時: 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、這時，重新執(zhí)行以下步驟即可：

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

但我在執(zhí)行g(shù)it svn rebase時，又出現(xiàn)沖突，這個時候，只需要手工合并掉沖突，并重新add一下：

1. git add . 

然后，再執(zhí)行：

1. git rebase --continue

如果報告說沒有修改內(nèi)容，則換成執(zhí)行：

1. git rebase --skip 

完成rebase過程，這時就可以git svn dcommit了。
這樣，總算解決了svn歷史沖突問題，不用象前面那樣笨笨的重新git-svn clone.

今天發(fā)現(xiàn)pg連上30多接近40個連接的時候出現(xiàn)連接失敗的狀況。感覺上好像在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

監(jiān)聽所有地址

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的經(jīng)驗吧。

開始

安裝最新版本的git，從git 1.5.3以后支持git-svn，git和svn的配合就要借助這個功能。

安裝完畢后要做一些簡單的配置。最直接的做法就是創(chuàng)建修改~/.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]部分標(biāo)示出使用者的身份，你提交的代碼會自動引用這一身份信息。[color]設(shè)置命令輸出的顏色。[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，已經(jīng)可以開始用它來進(jìn)行開發(fā)工作了。

不過，在開始開發(fā)之前，最好先做一次垃圾搜集：

git gc

它對代碼庫的信息進(jìn)行垃圾搜集和壓縮，最明顯的作用就是減小磁盤占用空間。第一次做效果尤其明顯。

你可以檢查一下代碼庫的狀態(tài)：

git status

現(xiàn)在應(yīng)該在一個叫”master”的分支(branch)上。

用這個命令來顯示出所有的分支(branch):

git branch -a

master前有一個*號，代表你現(xiàn)在所處的分支，另外還有一個分支叫trunk，它是一個遠(yuǎn)程分支(remote branch)，對應(yīng)的是遠(yuǎn)程svn代碼庫。master實際上是trunk的一個本地分支。

接下來，需要配置忽略文件，讓git忽略一些目錄中不希望加入代碼庫的文件，類似svn propset svn:ignore。全局有效的忽略文件列表可以添加在./.git/info/exclude文件中。比如我需要忽略所有vi產(chǎn)生的swp文件：

.*.swp

對于和目錄有關(guān)的忽略文件設(shè)置可以在該目錄下創(chuàng)建.gitignore，然后加入需要忽略的內(nèi)容，比如我希望忽略根目錄下的log,tmp等目錄，可以直接在根目錄下的.gitignore中加入:

log
tmp

開發(fā)流程

可以開始工作了。用git后開始養(yǎng)成一個新習(xí)慣，就是工作前先創(chuàng)建新分支:

git checkout -b new_branch

-b后是分支名，創(chuàng)建的同時，你要轉(zhuǎn)到了新分支上。盡量保持master上沒有未提交到svn的commit，這樣隨時都可以很容易的產(chǎn)生一個干凈的分支。

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

git diff

如果對某個修改不滿意，希望恢復(fù)原狀，可以使用:

git checkout path/filename

相當(dāng)于svn revert

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

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

然后提交

git commit -m "提交感言"

每次commit都是提交索引(index)中的內(nèi)容。

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

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

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

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

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

在修改加入所索引后，如果想看看索引內(nèi)容中都所了什么修改，可以用：

git diff --cached

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

查看最近一次提交的內(nèi)容，可以使用

git show

修改中隨時查看當(dāng)前代碼庫的狀態(tài)：

git status

相當(dāng)于svn status

刪除和移動某個文件：

git rm file
git mv file newfile

提交到svn

在完成了幾輪工作后，要將本地內(nèi)容提交到遠(yuǎn)程svn中，可以先讓當(dāng)前分支和遠(yuǎn)程svn同步：

git svn rebase

然后將所有已經(jīng)合并到master分支的本地修改提交到svn

git svn dcommit

如果在git svn rebase時發(fā)生代碼沖突，需要先手動解決沖突，然后用git add將修改加入索引，然后繼續(xù)rebase

git svn rebase --continue

缺點(diǎn)

最后說說這種工作方式的缺點(diǎn)。這個話題稍微復(fù)雜一點(diǎn)。

svn和git的工作原理畢竟不同，git對代碼提交的非線性特性在svn中難以再現(xiàn)，如果使用了git-merge或者git-pull，再提交到svn，相關(guān)分支上的提交歷史有可能無法體現(xiàn)在svn上。從svn的使用者的角度，無法辨別這是一個提交還是一次合并，所以在和svn協(xié)作過程中，盡量不要使用merge，或者說，盡量讓代碼庫保持線性。

我的經(jīng)驗是，如果不在乎svn中是否反映出提交歷史，使用merge也無妨。比如完成工作后，可以將工作分支合并到主分支中去：

git checkout master
git merge new_branch

先用checkout命令切換回master分支，然后將新分支中內(nèi)容合并進(jìn)來。然后在master分支上做git svn rebase和dcommit。從svn來看，這就是一個commit，new_branch上的提交歷史在svn上體現(xiàn)不出來。(有例外情況，以后再討論)。

還有一個解決辦法是盡量保持git代碼庫的線性特征。比如在new_branch分支中，先和master做rebase，再合并到master分支中：

git rebase master
git checkout master
git merge new_branch

然后在master上做dcommit，就可以在svn代碼庫中看到完整的提交歷史。

如果看到這已經(jīng)有點(diǎn)頭暈了，可以干脆不管它，就按照前面的做法，直接在你的工作分支里dcommit，等對非線性開發(fā)有一定了解再來看各種情況。

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

最近把版本管理系統(tǒng)換成git了，果然非常好用，難怪大家都在推薦。

首先不要有心理障礙，那些名詞都是嚇唬人的。所謂的“非線性開發(fā)”無非是指強(qiáng)大的branch和merge的能力，“分布式版本管理”就是說每人自己都有一套本地的repository，不存在一個集中的版本服務(wù)器。

給我?guī)淼淖钪苯拥暮锰幱校?

1. 傻瓜都會的初始化，git init, git commit -a, 就完了。對于隨便寫兩行代碼就要放到SCM里的人來說，再合適不過。也可以拿git做備份系統(tǒng)，或者同步兩臺機(jī)器的文檔，都很方便。
2. 絕大部分操作在本地完成，不用和集中SCM服務(wù)器交互，終于可以隨時隨地大膽地check in代碼了。
3. branch管理容易多了，無論是建立新的branch，還是在branch之間切換都一條命令完成，不需要建立多余的目錄。
4. branch之間merge時，不僅代碼會merge在一起，check in歷史也會保留，這點(diǎn)非常重要。

工具之所以好，除了方便好用，還在于它幫助并鼓勵你做正確的事情。頻繁check in是一件很好的事情，好處我不多說了，git就鼓勵你頻繁check in。branch也是一件好事情，我們大多很怕branch因為它太麻煩了，去掉這層心理包袱，branch可以讓我們的開發(fā)工作很有條例。

還有一些實用的功能，比如bisect,用二分法來尋找regression，你以前手動做過這種事么？我做過。以后如果要做就不會怕了。還有stash，做hot fix非常方便。

如果正在用svn，勸服所有合作開發(fā)者使用git之前，可以先用git-svn，和svn整合得非常好。

分布式版本管理系統(tǒng)取代集中式版本管理系統(tǒng)，只是時間的問題了。

    前段時間去北京出差，看了烈火和上水軒的項目，最大的感觸就是經(jīng)驗、人才的積累，個人的積累到項目組的積累到公司的積累，很強(qiáng)的個人能力，很好的團(tuán)隊氛圍，加上完善的公司團(tuán)隊支撐，大個一路羨慕，其實我第一次看到也很羨慕，不過積累這種東西不是一個人能撐起來的。平常心就好。

    還是說下架構(gòu)，這次去和左拉聊過之后，比較有感觸，但是依然有不贊同的地方，他堅持單服構(gòu)架，只是加入多線程設(shè)計使承載提升，上層倒是計劃用一些類似無縫地圖這樣的技術(shù)，但是我對單服承載能力和容錯能力依然表示懷疑。增加了出錯幾率和程序員調(diào)試時間，當(dāng)然這些我對他是沒底氣爭辯的，他完整的經(jīng)歷了兩個項目，經(jīng)驗是無法比的。

    我依然堅持我的底層多線程，邏輯單線程架構(gòu)，開發(fā)調(diào)試簡單。單線程邏輯能力的不足我用多服來分散。就我的經(jīng)驗來看，這樣對我目前的團(tuán)隊好處最大，因為服務(wù)端邏輯程序員都是新手，寫多線程程序經(jīng)驗不足，經(jīng)常死鎖、漏鎖。

    valgrind在內(nèi)存泄露方面還是不太好用，也只能是能用，但是其他方面倒是有一些意想不到的收獲，發(fā)現(xiàn)了幾處邏輯BUG，比如我的服務(wù)端線程accept到新的socket后就創(chuàng)建一個線程收發(fā)包，但是停止時我先停了accept線程，不掛valgrind就沒事，掛上就hang up在pthread_join位置上，郁悶很久，改了順序就完全ok。

    針對內(nèi)存泄露，我又找了一個很小的工具memcheck，效果出乎意料的好。我要的就是對malloc/realloc的內(nèi)存檢測是否free掉了。這個小工具也只有這個功能，在linux下面還能看到backtrace，不錯不錯。

    說到linux，不知道是我的錯覺還是什么，新底層在linux下跑的貌似確實要好一些，不是指速度，那個是肉眼無法觀察出來的，純粹的感覺，調(diào)試過程中的輸出、gdb給的反饋等等。怎么形容呢。感覺FreeBSD比較硬，更偏程序員多一些。linux就比較軟，替服務(wù)器管理員考慮的就多一些。純感覺。

金山有一套自己的服務(wù)端，單服務(wù)端，c++的，跑在CentOS上。代碼很龐大。維護(hù)起來不是很方面，而且個人感覺使用了太多的c++的特性。

第一次重構(gòu)服務(wù)端是剛來的時候，包括多服務(wù)端構(gòu)架，多線程底層，因為時間緊，使用的是我上一個服務(wù)端的大體框架，上一套服務(wù)器使用c++/stlport/boost/asio，邏輯是簡單了，但是問題也隱藏起來了，這次干脆使用純c代碼+libev。當(dāng)?shù)讓哟罱ㄍ瓿沙绦騿T開始工作后，我利用剩余時間重新考慮了一下服務(wù)端，首先被我放棄的是一開始就考慮上萬人承載、無縫地圖等等，把承載放在了比較合理的設(shè)計8k，實際5k一組上，經(jīng)過和其他部門的溝通，在構(gòu)架上也做了一些改動，避免了一處明顯的瓶頸設(shè)計。

再次重構(gòu)依然采用多服務(wù)端構(gòu)架，做了簡單的跨*nix平臺，目前在FreeBSD7.2和CentOS5.2上開發(fā)，底層是多線程，邏輯單線程，客戶端監(jiān)聽使用4個收，4個發(fā)來處理IO，服務(wù)端之間是一個連接一個線程，kqueue/epoll只針對客戶端監(jiān)聽使用，監(jiān)聽使用一個，4個收包線程一個線程使用一個。

邏輯線程就一個，簡單的從收到的包的隊列里取出數(shù)據(jù)然后處理。

都是些輕車熟路的東西，寫下來不到1000行代碼，效果還需要壓來測試。

在一次次重構(gòu)中，真正感覺到了簡單的美麗，現(xiàn)在的代碼連libev都拋棄了，kqueue/epoll簡單包裝了一下，純c的代碼運(yùn)用起來也漸漸得心應(yīng)手，沒有任何復(fù)雜的數(shù)據(jù)結(jié)構(gòu)，感覺很好。

valgrind終于進(jìn)行了重大升級，雖然features上提的是支持MacOS，但好歹和FreeBSD同源不是，3.5.0版本在FreeBSD上使用再也不需要mount /proc了，而且上個版本在FB7.2上根本用不成。這次表現(xiàn)的很好，雖然誤報依然一大堆，但好歹有報不是。終于不在FB上寫程序的時候提心吊膽了，以前可是根本就沒泄露檢測工具。反倒是CentOS上編譯valgrind失敗，好像是一個define的問題，沒去管它。

當(dāng)個項目總監(jiān)，特別是比較大項目的管理者還是很累的，不過我覺得做管理要有所依，服務(wù)端編程我不會放下，再忙每天都要抽出時間來寫幾段代碼，其實管理很簡單，我的風(fēng)格不喜歡搞太多事情，懶，但是做管理這樣是不夠的，缺乏強(qiáng)溝通、強(qiáng)推動。總覺得團(tuán)隊少了最核心的一點(diǎn)什么。努力！

別鄙視我，國情嘛。

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

IncrediBuild是一個很強(qiáng)的分布式編譯工具，可以明顯縮短大型項目編譯時間，但是價格不菲。對于我這樣的窮人來說，只能使用試用版。試用期限是30天，30天到了即使刪掉再安裝仍然不能使用。給Xoreax寫信申請延長試用期限，也沒給答復(fù)，估計針對個人他們根本就不讓延長試用。

令人郁悶的是，網(wǎng)上能找到的所有破解都是無效的。即使界面顯示已經(jīng)破解，但是時間一到，功能根本不正常。根本不會把編譯任務(wù)分發(fā)給別人，只能本機(jī)編譯了。

IncrediBuild 2.40的License有2個文件CoordLicense.dat和AgentLicense.dat，分別位于Coordinator和Agent安裝目錄下，這兩個文件都是RSA數(shù)字簽名過的，除非修改.exe文件中的解密密鑰，否則沒法偽造License文件。但既然網(wǎng)上能找到的破解都無法正常使用，所以肯定不容易搞定。對于3.20應(yīng)該也大同小異。

IncrediBuild在第一次運(yùn)行的時候會向注冊表中寫入軟件到期的時間。

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}

卸載軟件的時候并不會卸載這個注冊表項，所以重新安裝仍然不能使用。最簡單的辦法是卸載軟件后手動刪除這個注冊表項，然后重新安裝，就又可以繼續(xù)試用。還有一種辦法就是，我們定期更新上面這個注冊表項的值，把時間往后推移。還好該軟件時間算法并不復(fù)雜，很容易算出來。

比如說到期時間是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才會過期。

這個年齡了。眼鏡的度數(shù)應(yīng)該不會有太大變化了。

記下來吧。免得每次都要找借口去眼鏡店眼光

R –3.75 –2.00 X165

L –5.00 –2.00 X15

瞳距68

好記性不如爛筆頭

systat基本上是FreeBSD中最功能最多的系統(tǒng)監(jiān)視命令，顯示CPU、I/O、內(nèi)存、虛擬內(nèi)存、mbufs、磁盤IO、網(wǎng)絡(luò)狀態(tài)等信息等。

命令：

systat [-display] [refresh-interval]

其中 display 為我們所要顯示的信息項目，我們也可以在進(jìn)入 systat 后通過輸入“:display”變更顯示項目，refresh-interval 參數(shù)是需要多長時間采樣一次系統(tǒng)數(shù)據(jù)輸出到屏幕，單位是秒。

實例：# systat -vmstat 1

命令解釋：顯示CPU、I/O、內(nèi)存、虛擬內(nèi)存、mbufs、磁盤IO、網(wǎng)絡(luò)狀態(tài)等信息。信息采樣刷新時間為1秒。

以下為可用的 display 參數(shù)：

pigs 顯示目前系統(tǒng)中使用 CPU 最多的行程名稱。如果所有行程的 CPU 使用量未滿 100%，則多出來的部份顯示為 IDLE。
icmp 統(tǒng)計目前 ICMP 封包的進(jìn)出情形。
icmp6 顯示 IPv6 的 ICMP 封包進(jìn)出情形。
ip 顯示 IP 層的封包統(tǒng)計及 UDP 封包信息。
ip6 和 IP 一樣，但只顯示 IPv6 的封包。
tcp 顯示 TCP 的封包統(tǒng)計。
iostat 顯示 I/O 狀況統(tǒng)計，并分類為各種模式顯示。
swap 顯示目前各個儲存空間上的虛擬內(nèi)存的使用情形。
mbufs 顯示 mbufs 被使用的狀態(tài)。
vmstat 這是我們最常用的顯示模式，它顯示了最多的信息，包含 I/O、虛擬內(nèi)存、mbufs、網(wǎng)絡(luò)等信息。
netstat 顯示網(wǎng)絡(luò)的使用情形。
ifstat 顯示各個網(wǎng)絡(luò)適配卡的使用情形。

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

最快的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