Posted on 2007-04-14 14:54
laogao 閱讀(1719)
評論(3) 編輯 收藏 所屬分類:
Project Management 、
The Other Side
昨天(周五)大家下班后，一個人留在公司，把核心產(chǎn)品開發(fā)團隊使用了整整1年的CVS資源庫從CVSNT移到了Linux平臺下，原本以為會很簡單很順利，因為之前類似的移植并不是沒有做過，所以預(yù)估的時間包括驗證在內(nèi)是1~2個小時，不過最終卻花掉4個小時。怎么回事呢？且聽我慢慢道來。
經(jīng)過1年的積累，資源庫有400多M，大大小小的Java項目有206個之多。按照最初的計劃，移植只需要原封不動的把資源庫目錄整個從CVSNT服務(wù)器拷貝到Linux服務(wù)器即可，所以資源庫大小和項目多少本來不是啥大問題，但誰料半路卻殺出個程咬金：.jar文件在新的資源庫checkout到本地后無法正常使用，這還了得？
仔細(xì)一看，乖乖，原本"Binary"的文件，在新的資源庫下，卻變成了"ASCII -kkv"，不僅是.jar，其他的二進制文件如.jpg, .exe之類的也是同樣的問題。第一反應(yīng)是CVSNT和Unix經(jīng)典的CVS在處理RCS文件時還是有些不同，以至于原本在CVSNT下文件類別的標(biāo)記信息如"Binary"在移植過程中丟失了，變成默認(rèn)的文本類型。之前有朋友提醒的.doc文件移植后無法打開應(yīng)該也是同樣問題。怎么辦？一個文件一個文件的改？肯定不現(xiàn)實。
一種方案是把所有出現(xiàn)的二進制文件類型/后綴名找出來，然后在服務(wù)器端批量刪除(Linux下寫個腳本來做這件事并不難)，客戶端這邊從原資源庫checkout最新版本，重定向資源庫URL到新的資源庫，同步，提交。這招比較狠，但最終沒有用，因為在瀏覽現(xiàn)有資源庫時，發(fā)現(xiàn)還有不少其他問題，如classes文件夾被加到版本控制中，類似還有.settings文件夾，甚至Thumbs.db，不一而足。時間有限，與其每個Java項目去找一遍，整理出需要刪除的文件(夾)清單，然后寫腳本，然后強行資源庫重定向，不如一步一個腳印把現(xiàn)有資源庫的所有Java項目捋一遍，至少心里踏實。于是一狠心、一咬牙，有潔癖的我開始了漫長的"愚公移山"：一個項目接一個項目，遇到Binary文件，服務(wù)器刪之，客戶端checkout后從原來的地方拷貝過來，必要的地方加上.cvsignore，再添加提交。*
經(jīng)過4個小時的努力，終于大功告成：自動編譯腳本正確運行，構(gòu)建成功，客戶端IDE(Eclipse)從新的資源庫checkout，編譯通過，沒有紅叉。
后記：自己認(rèn)為計劃得再好的事情，真正去做的時候，總還是會遇到這樣那樣的問題和意想不到的狀況，這件事也告訴我自己其實我的前期準(zhǔn)備遠(yuǎn)不夠充分，算是自食其果吧。有沒有更好的辦法，我覺得肯定有，但是在特定的情況下(時間/效率/目標(biāo))，我相信我的方法還是能夠讓我自己滿意的。還有一點提醒所有CVS的用戶，不該提交的文件，最好第一時間加到.cvsignore。子曾經(jīng)曰過：“糾正錯誤，時間最早，代價越小”。
* 請勿不假思索的模仿，這樣做會丟失掉這些文件的歷史版本信息，如果刪除的時候不小心，同時還會把歷史上存在過的同類型文件刪掉。我這里之所以可以這么做，是因為我們的實際情況對這些二進制文件不需要保留歷史信息。