[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[cvs-ml 686] Re:ロック機能について
From: Atsuko TAMADA <atsuko@kke.co.jp>
Subject: [cvs-ml 683] Re: ロック機能について
Date: Tue, 25 Jul 2000 18:42:15 +0900
| 色々試みていたら、規則性（？）みたいなものがわかりました。
| 最初にimportしたリビジョンは1.1.1.1になるのですが、それに関して、
| lock⇒修正⇒commitすると、リビジョン1.1と1.1.1.1の二つのリビジョンを
| ロックされてしまうようなのです。
| リビジョンが1.2以降のものに関しては、同様の現象がおこりませんでした。
| だからと言って、原因がわかったわけではないのですが・・・
しらべてみた結果だけ書きます。
ファイルをimportすると,vファイルの状態は
o リビジョン番号は1.1.1.1
o デフォルトブランチは1.1.1
o headは1.1
になります。
admin -lすると、
o デフォルトブランチの先頭リビジョンをロックするか
あるいはheadをロックする。 ⇒ 1.1.1.1をロック
commitすると
o とにかくデフォルトブランチを抹消
o HEADリビジョンをロック ⇒ 1.1をロック
o deltaを追加するためにロックしているリビジョンを取得する。 (*)
o delta追加。
o ロック解放
問題なのは(*)のところにあって、commitしようとしているユーザはcommitし
ようとしているリビジョン以外はロックしていてはいけません。
この制約はRCSのciに由来していて、
- RCSではcheckinするにはそのリビジョンをロックしておかなくてはならない
- RCSにはCVS/のような作業ファイルの状態を記録する機構がない
という理由から、ciするときにロックされているリビジョンが
作業ファイルのリビジョンだと考えます。
もし複数リビジョンをロックしている場合には-rオプションで
リビジョンを指定することで対応します(これはRCSの話)。
今回問題になったのは、admin -lでロックしたリビジョンと、commitが一時的に
取得するロックのリビジョンが一致しないため、
(*)のところでロックが2つ存在してしまって、処理が中断したということです。
importをつかわずに
1. add
2. commit
3. admin -l
4. commit
というシーケンスの場合には3と4のロックが一致するのでよかったのですが
importをつかった
1. import
2. admin -l
3. commit
というシーケンスの場合には2と3のロックが異ったリビジョンになるので失敗します。
とりあえず、cvs adminでロックするときにデフォルトブランチを参照しない
ようにしてすればよいとおもいます。
一方、cvs admin -lはリビジョンを指定しないと
HEADリビジョンをロックしようとしますが
作業ファイルのリビジョンをロックしてほしいよなぁ、というのもありますね。
＃contrib/rcslock.plがつかえるかなとおもって試してみましたが
＃使いかたがわからん...
ところで、なぜロックをつかおうと思ったのですか?
--
KOIE Hidetaka 鯉江英隆 <hide@koie.org>