Re: [問題] 有關subversion 的使用問題,想請教

看板LinuxDev作者ggg12345 (ggg)時間16年前 (2008/10/05 09:10)推噓1(1推 0噓 2→)

留言3則, 1人參與討論串6/13 (看更多)

※ 引述《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