14

バージョン管理に関して私が読んだいくつかの投稿に基づいて、人々はバージョン管理システムでの悲観的なロックは悪いことだと考えているようです。なんで？ある開発者がファイルをチェックアウトしている間に別の開発者が変更を送信できないことは理解していますが、それでどうすればよいでしょうか? コード ファイルが非常に大きく、常に複数の人が同時に作業している場合は、コードを再編成する必要があります。より小さな機能単位に分割します。

並行コード変更の統合は、優れたバージョン管理システムが提供するツールを使用して簡単に行えるようにしても、退屈でエラーが発生しやすいプロセスです。できれば避けたほうがいいと思います。では、悲観的ロックが推奨されないのはなぜでしょうか?

4

10 に答える 10

14
  1. Source Safe で遊んで、開発者に 2 週間の休暇を取ってもらいます。それに加えて、VSS 管理者が不在です。投稿する修正がありますが、開発者のせいで投稿できません
  2. 複数の機能やバグ修正に取り組んでいる場合。コードがどれほど小さく分割されていても、中央ファイルに対する競合は発生します。
于 2008-09-26T16:08:27.873 に答える
7

一般的に、プロジェクトとチームによって異なります。悲観的ロックは理解しやすいので良いです - 一度に 1 つの開発者であり、マージは必要ありません!

ただし、悪い点はまさにそれです-一度に1人の開発者です。私は今、同僚がオンサイトに行って、彼が去る前にすべてをチェックアウトしたという状況を持っています。 、私とベースの残りの開発チームにとってお粗末です。

チームで悲観的ロックを回避できる場合は、それを使用しても問題ありません。実際、人々がそれを嫌う最大の理由は、Visual SourceSafe のデフォルトのプラクティスであるためです。多くの変更をマージすることに自信がない場合は、それを使用する別の理由があります。楽観的ロック SCM を使用してマージを開始したことがある場合は、回復がいかに難しいかがわかります。

マージを処理できる場合は、楽観的ロックが優れているのでお勧めしますが、使用したくない場合は、オタク カードを渡す必要はありません。

于 2008-09-26T16:17:18.803 に答える
6
  1. ボブは FooBar.java を編集する必要があります
  2. ジョンはそれを編集のためにチェックアウトしました
  3. とにかくボブは自分のローカル コピーを編集し、それを FooBar.java.bak として保存します。
  4. ジョンがチェックインすると、ボブがチェックアウトします
  5. Bob は、その上に FooBar.java.bak をコピーしてチェックインします。
  6. ジョンは彼の機能を再実装するようになります

私はそれが何度も何度も起こるのを見てきました。このプロセスは煩わしいため、開発者はこれを行います。

  1. ボブは FooBar.java を編集する必要があります
  2. ジョンはそれを編集のためにチェックアウトしました
  3. ボブはジョンが終わるまで親指をいじるのを待たなければならない

悲観的なロックはアマチュア時間のように感じます、ごめんなさい。

于 2008-09-26T16:32:59.983 に答える
4
  • ファイルを分割するオプションが常にあるとは限りません
    • 設定ファイル
    • XML ファイル
  • 比較的小さなファイルであっても、複数の開発者がアクセスする必要がある個別の部分を含めることができます
    • ライブラリ
    • ユーティリティ
  • マージ ツールは、これまでよりもはるかにスマートになりました
    • 競合はかなりまれです
  • 開発者がファイルを「誤って」チェックアウトすることによる遅延を減らします
于 2008-09-26T16:12:27.617 に答える
3

Bob と John のケースに関しては、svn のような協調システムは、ロック システムと同様にこのシナリオを防止しません。svn が最新版であることを満足させる FooBar.java を「更新」し、そのファイルをローカルで削除して、ベースライン バージョンを考慮せずに作成した自分の個人用コピーで上書きし、それをチェックインして、喜んで破棄することができます。相手の変化。ロックするかどうかに関係なく、これを防ぐシステムはないため、議論に持ち込む意味さえありません。

本当の問題は、あなたのバランスが何であるかを決定することです

マージミスの可能性と、ファイルをロックする人による不都合の可能性

ロックシステムまたは非ロックシステムのいずれかが「優れている」という考えはナンセンスです。

私は VSS をデフォルトのフル ロック モードで 6 人の開発者と一緒に使用しましたが、夢のように機能しました。時折、誰かがロックを解放するのを忘れて、彼らを追跡するか、手動でロックを解除し、戻ってきたときに手動でマージする必要がありましたが、これは非常に最小限でした. svn が自動マージを何度も台無しにするのを見たので、あまり信用できません。2 人のユーザーが同じファイルを自動的にマージできない方法で変更した場合、常に「競合」のフラグが立てられるわけではありません。
逆に、人々が VSS のロックに我慢できず、自分のコピーを編集し、他の人々のコードの上にずさんにチェックインするのを見てきました。

私が言いたいのは、これは賢明な議論ではないということです。どちらのシステムが成功するかは、どちらのシステムが優れているかではなく、競合点が発生したときにそれをどのように管理するかにかかっています。

于 2010-04-15T21:29:10.233 に答える
3

開発者が競合のマージと修正を処理できない場合は、再教育する必要があります。

小さなファイルでも競合が発生するのはよくあることです。たとえば、JSP の場合、ある人 (Web 開発者) がレイアウト コードを変更し、他の人が JSP が使用しているモデルの API を変更する可能性があります。

于 2008-09-26T16:13:15.070 に答える
2

悲観的ロックは (個人的な経験として) コラボレーションの妨げになります。良いチーム コミュニケーションによって簡単に置き換えられることもあります。「ねえ、しばらくこのいくつかのファイルで作業するつもりです」と言うだけです。

私は 2 人から 6 人のチームでロックせずに作業してきましたが、通常必要なマージ以外には問題はありませんでした。

また、 Visual SourceSafeでホストされているプロジェクトでロックを行ったこともあります。それは逆効果でした。

于 2008-09-26T16:09:34.987 に答える
1

深刻な競合が発生する可能性がある場合は、悲観的なロックを使用することをお勧めします。ほとんどのプログラミングでは、深刻な競合は発生しないため、悲観的なロックはかなり無意味です。これに対する例外は、次の場合です。

  • 実際にはマージできないバイナリファイルでの作業-アートアセット（モデル、テクスチャなど）が良い例です。
  • マージする方法を知らず、学びたくない非技術的なユーザーと協力する（ほとんどの場合、アーティストですが、一部のテクニカルライターもこれに適合します）。
  • 非常に複雑なため、簡単にマージしたり、小さなファイルに分割したりできない非常に大きなファイルでの作業（このような状況は直接見たことがありませんが、可能であると確信しています）。

さもないと...

于 2008-09-28T02:24:34.483 に答える
1

コード ファイルが大きすぎて、常に複数の人が同時に作業している場合

この場合、「人間」が責任を持ち、変更を調整する時が来ました。理想的なケースでは、プロジェクト管理がうまくいっていれば、ロックされたファイルを変更しようとすることはめったにありません。

つまり、'Bob' がコンポーネント X/Y/Z で大規模な変更を行っていることがわかります。コンポーネント X にバグ修正がある場合は、変更を送信する前に Bob に相談する必要があることがわかります。

私が言うように、これは理想的です;）

于 2008-09-26T17:28:32.907 に答える
1

ソフトウェア開発者は常に楽観主義者です。彼らの見積もりスキルを見てください!

実際には、競合が発生することはまれであり、ロックについて心配する必要がないという利点は、時折発生する競合解決手順よりも重要です。

于 2008-09-26T16:08:01.883 に答える