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