[cvs-jp-info 188] Re: 編集中のソースのロックは可能?

Back to archive index

Shun-ichi GOTO gotoh****@taiyo*****
2003年 7月 15日 (火) 11:55:57 JST


>>>>> at Tue, 15 Jul 2003 09:16:05 +0900,
>>>>> "若林 陽子" <wakabayashi_youko****@intec*****> said,
> 
> ただ、プロジェクトの事情もありまして、利用者が数十人に及んでしまい、
> なおかつ開発場所が離れてしまうため、どうしても密なコミュニケーション
> が取りづらくなることが予想されます。その場合にソースの
> 整合性が崩れてしまうことだけは何としても避けねばなりません。

この目的は理解できます。lockがもたらすのは大抵はファイル単位での編集権の
セマフォですから。でも、今までの話を聞く限り、lock の必要性はなさそうに
思いますし、懸案事項をlock で解消したとしても、別の問題を生むと思うよ、
という話です。

もしlock 相当を行なうとしたら、抑止すべきは編集の自由ではなく、commit の
自由でしょう。

その意味では(奨めませんが) cvs admin -l で目的は達成できるかも知れません。
その場合でも、『このファイルは私が重要な編集をするからしばらくcommit し
ないで下さい』と周知する必要はあるでしょう。


> また、ロックをかけることによって誰がソースを編集しているのかが
> 明確にわかれば、「あなたがロックしているソースの1つを
> 少し直したいのだけど、15分だけロックを外してもらってもいい?」と
> いった交渉がしやすくなるというメリットもあると思います。
> (ロックしている利用者が誰かわかることが条件になりますが。)

はたしてそれはメリットでしょうか? そういう悠長な交渉をしている余裕がある
状況なのならそれもいいかも知れませんが、コミュニケーションが密にとりにく
い状況っていうくらいだから、更に面倒なことになりそうに思えます。同じ職場
の同じフロア同士でもロックによるイライラは募り、本来の作業以外の手間が増
えるものです。

だれが編集中かを意識させるという点に関しては、cvs watch / cvs edit がふ
さわしいでしょう。

# コミュニケーションの不足をツールで補助はできるのは確かですが、
# lock で不足をおぎなうというのはかなり一方的なものですし、
# それではコミュニケーションは向上しないことでしょう。
# 本質的にはコミュニケーションを補う方向で、メーリングリストを立てるとか、
# IP Messenger やnet meeting のようなリアルタイムなツールを使う
# 方向で補った方が良いのではないかと思います。


塩野さんもいっているように、ロック機構をもっているツール類の大抵は、編集
中はロックを外せないところがポイントではないでしょうか。

A: 『... 15分だけロックを外してもらっていい?』
B: 『今作業中でまだコンパイル通らないんです。30分ほど待って』
A: 『ということは私も30分コンパイル通せないということか。。。』
B: 『未完成でも何とかコンパイル通るところでcommit しましょうか?』
A: 『でもそれじゃマトモには動かないんでしょう?』
B: 『えぇ。。。』
A: 『うーん』
B: 『じゃぁ、私が修正したファイルをコピーしておいて一時的に
     元の状態にしてロックを外すよ。(ち、面倒だなぁ)』
A: 『おねがいします』
B: 『(ふぅ、その間私はなにしてようか...)』
A: 『(ふぅ、たった数行編集するだけなのにめんどうだなぁ)』


cvs のやりかただと『このファイルはcommit しないでおいてね』だけで済みます。
# 一見不安なのもわかりますが。

たとえ自分の編集作業中に別の人にcommit されたとしても、互いの修正が意味
的にconflict していなければ問題ありません(整合性は失われません)。

意味的にconfilict しているようなケースは、そもそも両者が行なおうとした変
更内容/目的自体に問題があります。これは両者が話し合ってが解決するしかあ
りません。

cvs merge によるマージ処理に失敗した場合でも、cvs はソースの全修正履歴を
持っていますし、merge 前の編集中ファイルのバックアップも残してくれますの
で、原因解決が出来ます。

それでも安易に修正して欲しくないクリティカルな内容のファイルがあるとすれ
ばそれはlock ではなく、修正方針などを各人に徹底させることこそが重要でしょ
う。

lock はそういった複数の小さな煩わしさを、別の1つの大きな煩わしさに置き換
えることで排除しているように見せかけているようなものではないでしょうか。

--- Regards,
 Shun-ichi Goto  <gotoh****@taiyo*****>
   R&D Group, TAIYO Corp., Tokyo, JAPAN



CVS-JP-info メーリングリストの案内
Back to archive index