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的問題，沒去管它。

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

這個年齡了。眼鏡的度數應該不會有太大變化了。

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

R –3.75 –2.00 X165

L –5.00 –2.00 X15

瞳距68

別鄙視我，國情嘛。

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才會過期。

好記性不如爛筆頭

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