subversion 的使用問題,請教

[粽子]

各位大大 :

今日在幫同事導入 subversion&指導如何操作subversion, 來幫助工作團隊維護專案品質.不過再跟同事討論關於"多人共同維護同一個檔案"時,討論到了一個我從來沒有想過的情況.

subversion 只有在同一行被重複修改的時候才會跳出衝突對吧?

假設一個檔案有3行,有兩個人共同維護
L1
L2
L3

A修改了第二行,刪除第三行,變成
L1
L22


B 修改了第一行,變成
L11
L2
L3


A先commit , 然後B也要commit 時就冒出了"過時(out of date)",這很合理.接下來B就必須合併A的更改,才能commit.
當B執行合併時,B的檔案就會變成
L11
L22

可以發現第三行不見了.因為A把第三行殺了.
結果同事就說 "假如L3 是對B的工作上是很重要的一行,A不應該刪除"
我 : "那B在執行合併完,重新開檔的時候就會發現L3不見拉,他就可以去跟A抱怨"
同事 : "那是範例,現實上一個程式檔案那麼大,好幾千行,我不可能重新開檔的時候會看到我需要的部份被別人刪除了壓"
我 : "也是...."
同事 : "所以我在別家公司的作法是,每個人規定一個固定時間才能commit,commit 的時候如果發現過時,就不要先合併別人的更新,而先檢查別人的更新跟自己的部份有哪邊不一樣."
我 : "那這樣不就要一個人commit 後,其他一堆人就得放下手上的事情,每個人都來檢查哪邊被改了,這樣不合理拉,如果更新範圍跟複雜度很大,那不就要沒完沒了,光檢查就花一堆工,事情不用做了"
同事 : "所以,我們以前的作法是一個檔案只定給某個人改,其他人不能改,這樣就不會產生那樣的問題"
我 : "那這樣還需要版本控制軟體幹麼?"
同事 : "對壓"
我 -> Orz

這個問題,我覺得最根本在於
"B如何告知他人L3是不可以修改的"
或者是
"B憑什麼決定L3不能修改,B說不能修改就不能修改嘛?"
或者
"B怎麼樣可以知道他認為不可以修改的地方被改到了,難道只有不停的diff 來檢查嘛?,搞不好時間一久,B連哪邊是不可以修改的部份都忘了,這時連diff 檢查都幫不上忙"

後來我一直問google ,不過沒有找到.
所以我po這篇文章,懇請站上的大大幫忙.如果哪位大大有認識一些subversion的高手,可不可以幫忙把這樣的問題pass 給subversion 的前輩呢?

在這邊先謝謝了

[peterpan]

我們也用svn，不過很少遇到這樣的問題
基本上project不要太大的話，每個rd應該都多少知道那些code是可以改
那些code是不應該動的。
也許svn不是萬能的，但至少能解決大多數的問題

[70630515]

所有的撰寫、修改及校正皆需透過申請，審核通過後才能動工

[性感的尤物]

樓上的在寫什麼東西呀！我，一個字都看不懂。

-----------------------------
我不擔心，因為我封閉(Closed)，我很興奮，因為我賺錢(Intellectual Property)-Proprietary Software

[legnaleurc]

前提有點怪, 個人不太懂:

1.
A和B維護的是同一份code(或是同一個branch), 因此每個段落的重要性對A和B來說應該是一樣的( 如果你們用的是git那情況又不同了= = )
如果某段落對B很重要,那麼對A來說也很重要,A不應該把它移除的
真的發生這種事, A事後應該會很悽慘....

2.
如果某段code對A和B的意義不相同,那麼代表他們的目標是不一樣的
這兩個人應該要在不同的branches工作才對

3.
merge前先看清楚diff的結果不是天經地義嗎?QQ

4.
B在commit之前永遠有機會找A溝通, 如果B真的認為某段code不可以改, 他可以在註解上解釋清楚

[粽子]

[quote="legnaleurc"]前提有點怪, 個人不太懂:

1.
A和B維護的是同一份code(或是同一個branch), 因此每個段落的重要性對A和B來說應該是一樣的( 如果你們用的是git那情況又不同了= = )
如果某段落對B很重要,那麼對A來說也很重要,A不應該把它移除的
真的發生這種事, A事後應該會很悽慘....
[/quote]
1.的情況是有可能發生的
因為某段落重不重要跟他是否會被刪除毫無關係.刪除某段落並不是某段落不重要了,可能是換了演算法,或邏輯時序,或介面名稱,而有可能刪除原本需要但後來不需要的行或段落.

假如A是C++ class owner,B是 class user . A 可能覺得a method 已經不需要獨立出來,可以併到b method裡面.但B不知道這件事情.仍然呼叫a method,這個情況就發生了

但是不管對A對B是否重要.這種情況如果真的發生了,無法在merge 時發現,我是希望找到辦法或工具或svn 選項可以盡量早先發現這種情況.因為,現實是,就算A到時候真的很悽慘,也挽救不了project delay 的

[quote="legnaleurc"]
2.
如果某段code對A和B的意義不相同,那麼代表他們的目標是不一樣的
這兩個人應該要在不同的branches工作才對
[/quote]
2.的方案的確是我沒有想到的一個有用的方法

[quote="legnaleurc"]
3.
merge前先看清楚diff的結果不是天經地義嗎?QQ
[/quote]
我的思考角度是想到說,今天如果不是A跟B兩個人.而是5個人.那麼,一個人commit.下一個commit 的人就要放下工作,diff , merge , and commit .然後第三個又重複同樣的工作.接下來第四個人,第五個人....
另一個考慮的因子是,如果source 放的久了,忘記了某個段落的功能.就算diff後發現那個段落不一樣.merge 的人也沒有辦法立即的意味到"危險",以為Ok就給他merge.結果到project整包抓出才發現

如果有衝突才去diff ,有矛盾才來溝通,這是我比較想要的一個方式.

[quote="legnaleurc"]
4.
B在commit之前永遠有機會找A溝通, 如果B真的認為某段code不可以改, 他可以在註解上解釋清楚
[/quote]
4.的方法也是一條路.

謝謝legnaleurc的指教.也希望有興趣的svn之友一起加入討論

[legnaleurc]

1.的情況是有可能發生的
因為某段落重不重要跟他是否會被刪除毫無關係.刪除某段落並不是某段落不重要了,可能是換了演算法,或邏輯時序,或介面名稱,而有可能刪除原本需要但後來不需要的行或段落.

假如A是C++ class owner,B是 class user . A 可能覺得a method 已經不需要獨立出來,可以併到b method裡面.但B不知道這件事情.仍然呼叫a method,這個情況就發生了

我先就你舉例的部分討論, 如果沒抓到重點請見諒
如果A做的更改是"正確"的話
那麼針對演算法或是實作面的更動應該是不會影響到其他人的
而對interface的改變, 如果我沒想錯的話, 這東西要嘛就從來都不改, 要改就是整份code一起改, 而且還要通知其他所有成員
如果A不自己把整份code改掉,他的部分一定會出現compile error
而送交不能compile的東西上repo本來就是大忌

但是不管對A對B是否重要.這種情況如果真的發生了,無法在merge 時發現,我是希望找到辦法或工具或svn 選項可以盡量早先發現這種情況.因為,現實是,就算A到時候真的很悽慘,也挽救不了project delay 的

所以你希望工具來判定人送交上去的code合不合理?
我是覺得這超出VCS的範圍了....至少我不希望電腦來決定我改的code是不是對的

我的思考角度是想到說,今天如果不是A跟B兩個人.而是5個人.那麼,一個人commit.下一個commit 的人就要放下工作,diff , merge , and commit .然後第三個又重複同樣的工作.接下來第四個人,第五個人....
另一個考慮的因子是,如果source 放的久了,忘記了某個段落的功能.就算diff後發現那個段落不一樣.merge 的人也沒有辦法立即的意味到"危險",以為Ok就給他merge.結果到project整包抓出才發現

如果有衝突才去diff ,有矛盾才來溝通,這是我比較想要的一個方式.

呣....我是在使用VCS時永遠都假設上一個送交是"正確"的
"錯誤"或是有bug的送交應該是人自己要解決的問題
我覺得這很像要求compiler檢查你的程式有沒有無窮迴圈

反過來想
如果你們沒有使用VCS
到時候發現有問題的code要怎麼復原?
而你們同事提到的做法
我個人會對那個project leader致上最深的敬意與同情
因為如果一次的merge有幾千行的話
那一段時間的merge只由一個人處理....
希望他能長壽XD

=======

如果硬是要做這種line lock的勭作
在diff merge的時候會惹上麻煩
因為就算A實際上沒動到B要保留的那幾行
可是有時diff的結果還是會把那幾行先刪掉, 再插到其他位置(比方說code順序對調時, 最常發生在refactor的時候)
這種時候可能就只能選擇很糟糕的那個diff結果(為了不刪除那十行而把其他幾百行重寫, 可能會增大檔案庫)
或是根本merge不起來
這是對Subversion實作上的困難

[粽子]

真的,真的很感謝大家的經驗分享.
你們的經驗讓我知道該怎麼做了

另外,git 好像還沒在台灣流行起來...

[legnaleurc]

git還不錯用啦....只是目前支援沒有比Subversion豐富
我現在都用git說, git比較有"工具"的感覺
Subversion用起來有時會受到專案的束縳
雖然強者用起來可能都是一樣的QQ

[粽子]

git 有中文教學資料嘛?
謝謝

[legnaleurc]

這網站不錯:
Git 原始碼管理 - 國家高速網路與計算中心 Ruby on Rails 推廣

其實git官網的文件也滿多的

[guest]

我是原po
這個問題過了兩年,發現mercurial 跟 git都能處理
分散式的版本控制的確可以比subversion 處理更多隱昧的問題

[訪客]

前提有點怪, 個人不太懂:

1.
A和B維護的是同一份code(或是同一個branch), 因此每個段落的重要性對A和B來說應該是一樣的( 如果你們用的是git那情況又不同了= = )
如果某段落對B很重要,那麼對A來說也很重要,A不應該把它移除的
真的發生這種事, A事後應該會很悽慘....

1.的情況是有可能發生的
因為某段落重不重要跟他是否會被刪除毫無關係.刪除某段落並不是某段落不重要了,可能是換了演算法,或邏輯時序,或介面名稱,而有可能刪除原本需要但後來不需要的行或段落.

假如A是C++ class owner,B是 class user . A 可能覺得a method 已經不需要獨立出來,可以併到b method裡面.但B不知道這件事情.仍然呼叫a method,這個情況就發生了

但是不管對A對B是否重要.這種情況如果真的發生了,無法在merge 時發現,我是希望找到辦法或工具或svn 選項可以盡量早先發現這種情況.因為,現實是,就算A到時候真的很悽慘,也挽救不了project delay 的

Looks like you may need software e.g. Hudson for continuous integration.