推 tinlans:我是覺得靠 programming 的技巧就能簡單迴避這類問題，不 10/07 05:22
→ tinlans:過因為會離題太遠就沒有多說什麼了。 10/07 05:22
→ tinlans:國科會的話，目前我看過做系統的實驗室大都至少會用 CVS。 10/07 05:23
※ 引述《leolarrel (真.粽子無雙)》之銘言：
: 今日在幫同事導入 subversion&指導如何操作subversion, 來幫助工作團
: 隊維護專案品質.
: 不過再跟同事討論關於"多人共同維護同一個檔案"時,討論到了一個我從來
: 沒有想過的情況.
: subversion 只有在同一行被重複修改的時候才會跳出衝突對吧?
: 假設一個檔案有4行,有兩個人共同維護
: L1
: L2
: L3
: L4
:
: A修改了第二行,第三行,變成
: L1
: L22
: L33
: L4
:
: B 修改了第一行,變成
: L11
: L2
: L3
: L4
:
: A先commit , 然後B也要commit 時就冒出了"過時(out of date)",這很合理.
: 接下來B就必須合併A的更改,才能commit. 當B執行合併時,並不會產生衝突警
: 告,接著B的檔案就會變成
" L11
: L22
: L33
: L4
:
: 結果同事就說 "假如L3 是對B的工作上是很重要的一行,A不應該修改.結果A去
: 改到了,B沒有收到警告"
:
: 我 : "那B在執行合併完,重新開檔的時候就會發現L3被改掉拉,他就可以去跟A抱怨"
:
: 同事 : "那是範例,現實上一個程式檔案那麼大,好幾千行,我不可能重新開檔的
: 時候去看到我需要的部份被別人改了壓"
:
: 我 : "也是...."
:
: 同事 : "所以我在別家公司的作法是,每個人規定一個固定時間才能commit,commit
: 的時候如果發現過時,就不要先合併別人的更新,而先檢查別人的更新跟自己的
: 部份有哪邊不一樣."
:
: 我 : "那這樣不就要一個人commit 後,其他一堆人就得放下手上的事情,每個人
: 都來檢查哪邊被改了,這樣不合理拉,如果更新範圍跟複雜度很大,那不就要沒完
: 沒了,光檢查就花一堆工,事情不用做了"
:
: 同事 : "所以,我們以前的作法是一個檔案只定給某個人改,其他人不能改,這樣
: 就不會產生那樣的問題"
:
: 我 : "那這樣還需要版本控制軟體幹麼?"
:
: 同事 : "對壓"
:
: Orz
:
: 這個問題,我覺得最根本在於
: "B如何告知他人L3是不可以修改的"
: 或者是
: "B憑什麼決定L3不能修改,B說不能修改就不能修改嘛?"
: 或者
: "B怎麼樣可以知道他認為不可以修改的地方被改到了,難道只有不停的diff 來
: 檢查嘛? 搞不好時間一久,B連哪邊是不可以修改的部份都忘了,這時連diff 檢
: 查都幫不上忙"
:
:
: 後來我一直問google ,不過沒有找到答案.svn 只能對重複修改的地方產生衝突
: 警告. 所以我po這篇文章,懇請站上的大大幫忙,svn是否有提供工具解決這樣的
: 問題? 用人類行為約束的方法是很多,但是我還是希望svn 方面有提供工具.
: 如果哪位大大有認識一些subversion的高手,可不可以幫忙把這樣的問題pass 給
: subversion 的高手呢?
:
: 在這邊先謝謝了
:
: --
: ※ 發信站: 批踢踢實業坊(ptt.cc)
: ◆ From: 116.59.13.7
: 推 kene:把重要/該獨立的部分獨立出來, 這種情況即使用別種版本控制系 09/23 17:01
: → kene:統依舊會出問題, 最好的方法是將該檔案模組化 09/23 17:02
: → leolarrel:所以,還是只能用人類約束的方式解決呼? 09/23 17:16
: 推 kene:是啊, 軟體只能幫你把處理 conflict 的流程簡化, 但沒辦法幫 09/23 17:52
: → kene:你把 conflict 自動去掉 09/23 17:53
: 推 kbslave:這是心態的問題～Conflict不代表你就要相信SVN Merge的能 09/23 20:55
: → kbslave:力..還是在conflict發生時，Diff一下才是有禮貌的 09/23 20:56
: 推 MortonRainey:遇到conflict時，可以進行pair programming, 馬上找 09/23 22:22
: → MortonRainey:出通解，相信只要不堅持自己寫的最棒的原則，總是可 09/23 22:22
: → MortonRainey:以有符合雙贏的解法，否則各搞各的鐵定出其他問題! 09/23 22:24
: → leolarrel:咦,對不起,各位大大好像有誤會.我舉的例子,SVN是不會 09/24 00:02
: → leolarrel:產生Conflict警告的 09/24 00:02
: → antontw:那不是 conflict 是 merge ， svn up 時有 G 標籤會跑出來 09/24 00:42
: 推 adrianshum:關於: B如何告知他人L3是不可以修改的, 最好的方法就 09/24 17:49
: → adrianshum:是靠 Unit test. B 覺得 L3 重要, 就要寫 test 試到 09/24 17:50
: → adrianshum:L3 帶來的 expected behavior. 09/24 17:50
=========================================================
前幾天有人提到做國科會 open source 計劃的, 應該被要求必須使用這種
工具來訓練參與者加強團隊合作的訓練. 看到這串如何利用 subversion 工
具的討論, 就想到該請教一下各位在推廣使用上, subversion control 的
正反面的效益如何 ?
看見這串討論就是覺得: 假如 L3 對 B 是很重要, B 當然要擔心, 那就要
協調出他負全責去管理維護, 那就變成是要 B 同意才能改. 但 A 會去更
改, 那必然就是 A 會用到, 那 A 的需求規格是甚麼 ? 會與 B 的需求規範
起衝突 ? 這不外乎兩者的需求功能能分割清楚嗎 ? 如果不想協調, 想要省
事各幹各的, 其一就是 A 複製一套 L3 為 AL3 , 再完全 "獨立使用(Read
only 不能 update 共用的部份)", 也就是併行的兩條路各自分道揚鑣. 另
一辦法就是合併需求找通解, 也就是建立串接項目(共用的部份)前後的分叉
(branch)項, 為了確保自己想要的部份不被污染干擾, 那就會建立測試項彼
此讓對方代替自己檢查. 此時的 B 或 A 就只靠設計各自的 test data 來
管理與確保自己部份的正確性, 也就不必凡事親管, 事必躬親的維護.
理想的狀況就是一群人用對了工具, 有了正確的用法(有如架構, 機制, 演算
法), 就像一堆散沙病貓坐進有通信協調的坦克, 就自動變成了無堅不摧的豺
狼虎豹.
不曉得這個 subversion tool 是不是值得國科會這樣硬推 ? 業界用得很多
嗎 ? 學校該怎麼教育訓練讓學生能挑選工具也能正確使用 ?
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.115.4.12