アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
ロックは要らんかねー？ (スコア:1)
ロック・修正・ロック解除の解法 [bluegate.org]
を見るたびに思うんだけど、ロック方式ってそんなに全否定されるべきものなんでしょうか？
まず、適切な「マージ」が定義できないファイル形式(すなわちdiffがあまり意味をなさない形式)については、
この「更新が衝突したら、あとでマージすればいいでしょ」という戦略は
戦略自体が適用不可能なのでは？という疑問が拭えません。
よく知らないんですが、もしかしてSubversionの「マージ」は
オブジェクト指向のように「多態」することが出来るんでしょうか？
つまりファイル形式ごとにマージアルゴリズムを変えたりできるんでしょうか？
＃例えばXMLで言えば、Tree構造のマージをするのかとか、スキーマが同一じゃないXMLファイルはマージを拒絶すべきかとか、色々課題はありますよねー。
＃また例えばBMPなら、絵を混ぜるってのはどっちを上にすることを意味するのか？とか(^^;
…というか、最悪、マージが「事実上定義不可能」なファイル形式なんて、幾らでもありえるわけで…
まあ、マージ作業をソフトが一切支援しないという「アルゴリズム」もありえますが、
そんなことされるくらいなら、ロック方式のほうがマシなわけでして。
あと、それよりやや弱い主張として、
「バージョン管理ツールに、ロック管理を兼ねさせたいことも、有っていいのでは？」
というのもあります。
細かくいえば確かに、バージョン管理にロック管理をさせるのはオフトピ(^^;だ、という解釈も
ありえそうですが、そこまで細かくツールを分けるのは簡便性を損ねるだけじゃないかと。
そして勿論、「ユーザ間のコミュニケーション」という人的作業は、間違えたり忘れたりしたらアウト、
という性質を持っているのはご存知の通り。
つまり、
＞衝突を解消するのにかかる時間は、ロックするシステムで失われる時間よりもずっと短いのです。
という主張は、状況によって成り立たないことも結構有るのでは？という話です。
古臭いCVSみたいに(^^;古典的なテキストファイルのみをお客さんとするならば、それでも構わないのかも知れませんが、
Subversionは任意のファイル形式をお客さんにしようとしてるのです(よね？)から、
この辺をなんとかして欲しいなあと。
CVSでも採用されてる非ロック(マージしろよ)戦略って、
それを選択するかどうかは、ツールにおいて切り替え可能になっていて欲しいなあ、と
思ってる昨今です。状況や用途によってロックか非ロックかを(できればファイル単位で)設定できたらいいな。
ちなみにどうでもいいですが、仕事で扱ってる某OODBでは、
オブジェクトのバージョン管理の概念が有るんですが、これもロック方式です。
まあ(任意の)オブジェクトに対してマージが定義できるはずもないですし、
構造も量も膨大な情報量をもつデータ(CADとか)に対して
「(しばしば人力で)マージしろ」なんて無茶な要求なわけです。
なお当然ですが(VSSやRCSと同じように)、編集権限(ロック)を得ずにReadOnly取得するという機能も有ります。
職場でMSWordファイルの共有をどうしたものかと悩んでいるのでG7
…っていうか、Winでドキュメントな世界の連中(^^;に、「バージョン管理ツール」を普及させたいんですが、
上記の問題が解決してくれないと、使えないんですよね。
＃ここでいう「世界」とは、出来れば本当の意味での世界全体であって欲しいです。
＃バージョン管理もなしに複数人がファイルを更新する状況は有ってはいけない、ってのは
＃OpenSourceな我々(^^;は文化として充分に知っていることなわけですが、
＃その文化を世間に「輸出」してもいい頃合なんじゃないか？と俺は思うんです。
＃幸いDiskは安くなりましたから、パソコンを使う「全ての」人がバージョン管理の恩恵を充分に受ける時代が来ても、いいはず。
業務での開発においてはロックは不要だと思います (スコア:0)
必要かもしれない、と思った瞬間はありますが、それは、「ルールを守らないメンバーに対するフェールセーフ」でした。しかし、そもそも、プロジェクトにそんなメンバーがいること自体が問題であり、それは、技術的に解決するものではないと思います。メンバを「ルールを守らせる」という方向で教育したり、よくコミュニケーションをとることで、解決することが多かったです。
また、おなじソースを同時に複数のメンバーがつつくような状況というのは、ひとつ
ソフトのソースに限った事情なのかも＞非ロック (スコア:1)
確かにソースについては、俺もロック要らねーなと思うんですが、
それはソースというものの(特殊)事情に拠るんじゃないか？と。
事情とは、例えば、
○テキストである。行指向であるか、そうでないにしても人間の目を併用すれば行指向もどきと見なせる。→diffに意味が有る
○各ファイルが、機械は勿論、人間にとっても、ほどほどの大きさである。規模という意味で可読性が有る。→マージ作業が可能
○その内容(意味)において、ファイル間の依存関係が、結構強いし複雑だ。→ファイル単位のロックは非常に頻繁に無意味
といった所でしょうか。
これら(とか)を満たすデータならば、非ロック型管理が向いているんだと思います。
＃ちなみに「業務」かどうかは無関係だと思います。OpenSourceみたいにしばしば業務じゃないものでも非ロックは有効です。
でも、そうでないデータなんてものも、世の中には一杯あると思います。
○テキストでない。→Wordファイル(^^;やCADファイル
○あるいはテキストでも(物理)行指向っぽさが乏しい。→XMLの行指向diffって意味有るの？
○大きすぎる→巨大なファイルなんて幾らでもあるでしょう。
○ファイル間の依存が無いか少ない。→それこそワープロとかだと、わざわざそうしない限り、依存関係なんてあんまり無いですよね？
で、そういう分野であっても、バージョン管理そのものは充分有用なのです(いちいち説明は不要と思いますが)。
だから普及して欲しい。
せっかくだからOpenSourceモノが(^^;。
Officeソフト用にゃ高額な商用のVersion管理ツールしか無い、ってのは寂しいんで。
-----
>また、おなじソースを同時に複数のメンバーがつつくような状況というのは、
>ひとつの機能に対して複数の修正を複数のメンバーがかけていることになります。
ん？それは非ロック(マージ)方式を否定する話になってしまうのでは？
単に「同一ファイルは同時にいじっちゃいけない」という話をするだけでいいならば、
ロック方式のほうがマシです。なにせ同時にいじらないことをシステムが保障してくれるんですから。
マージ方式ってのは、「それでもやっぱり、同時にいじることは避け難い」
という処から話が始まっているんだと思いますが。それこそLinuxのソースとかね。
ソースについては、それこそアスペクト指向でも全盛にならない限り(^^;、
同時にいじるのは避けられない状況が続くと思います。
関数型だろうがオブジェクト指向だろうが、そういう問題は(常にではないけどイツかは)不可避になります。
>無駄に思えるかもしれませんが、小さい修正をひとつひとつ検証していただくほうが、全体の作業量は抑えられるように思います。
あのー？それならばロック方式でもいいじゃないですか？
つまり、どうせ(1ファイルまたは1プロジェクトについて)同時には一人づつしか修正作業をしない、
っていう話なのですよね？
それならロックしても(しなくても)痛くないですよ。それだけのこと。
…ところで余談ですが、開発においては「全体の作業量を抑える」ことが最優先事項だ、というわけではないと思います。
どっちかってーと「結局かかる時間を抑える」のが最優先じゃないかな。
だからこそ(ソースでは)非ロックが役立つんだと思います。マージが。
つまり同時編集を敢えて見逃してあげる(そして後からマージによってフォローする)ほうが「速い」ということなのでは？
マルチスレッドの話と同じで、複数のアクター(開発ではプログラマ)が衝突を「気にせず」作業できる状態が、一番速いっすよね。
>ロックがかかったまま解除できなくなってしまったソースが大量発生し、にっちもさっちも行かなくなりました。
あのー。あなたが忌避なさってるのは、「ロック」じゃなく「同時編集」なような気がするのですが？
つまり、CVSとかを使っても、単に「修正を誰かがコミットし忘れてる」という恐れを「無視」してるだけ、
だったりしませんか？
一部のものに限った事情なのかも＞非ロック (スコア:1)
(リレーショナル)データベースで、
行をロックするっていう概念はしばしば聞きますが、
行をマージするなんて話はついぞ聞いたことが無いです。
既に書きましたが、やっぱりテキストで行指向で…という限られた状況を満たすフォーマットだけが
非ロック(マージ)方式を採れるんだと思います。
で、任意のフォーマットが、バージョン管理の恩恵に与れるといいなぁと思うわけです。
＃いずれはMicrosoft Versionとかいうソフトが出るんだろうなと思うのでG7
＃あるいはOSに抱き合わせかな。そういや将来のWinはFilesystem自体をDBにするという案も有ったんでしたっけ。
> その経験が、反ロック、の考え方の源流になっていることは否定しません。
任意のファイルを扱う場面で、バージョン管理ツールを使うという状況を
ちょいと(経験していないならば)想像してみてください。
まさかソースみたいなもの以外はバージョン管理は使わないほうがいい、なんてことは
思われませんよね？
Re:一部のものに限った事情なのかも＞非ロック (スコア:1)
Microsoftがやる前に、Adobeが、VersionCue [adobe.co.jp]というソフトを出しています。
Adobe Creative Suite [adobe.co.jp]ていう統合パッケージと抱き合わせです。