3

私は数年間ソースコントロールを使用してきましたが（ソースセーフの年数を数えると）、決して専門家ではありません。現在、古いバージョンのSourcegearVaultを使用しています。私たちのチームは現在、チェックアウトとロックのモデルを使用しています。むしろアップデートとマージモデルに切り替えたいのですが、他の開発者を説得する必要があります。

開発者（私ではない）がチェックアウトとロックとして機能するように設定した理由は、ファイルの反逆によるものでした。当社はコンサルティング会社と協力して開発作業の多くを行っています。数年前、私がここにいるずっと前に、彼らは更新とマージのためにソース管理を設定していました。コンサルタントはチェックインに行きましたが、マージエラーが発生しました。その後、彼らは数ヶ月間切断モードで作業することを選択しました。ついにプロジェクトをテストする時が来たとき、たくさんのバグが現れ、コードベースが劇的に異なっていることが発見されました。何週間もの作業は、やり直さなければならなくなりました。そこで彼らは解決策としてチェックアウトしてロックしに行きました。

2人以上が同時に同じプロジェクトで作業するのは非常に難しいので、チェックアウトしてロックするのは好きではありません。任意のタイプの新しいファイルを追加したり、ファイルの名前を変更したりするたびに、ソース管理は.csprojファイルをチェックアウトします。これにより、他の開発者がファイルを追加/名前変更することができなくなります。

ファイルだけをマージ可能にすることを検討しました.csprojが、csprojはIDEで自動生成され、2つの異なるVS生成ファイルが同じコードを生成することを保証できないため、Sourcegearサイトはこれは悪い考えだと言っています。

私の友人（他の開発者）は、解決策はプロジェクトをすぐにチェックインすることだと言っています。私にとって、これに関する問題は、ビルドされないローカルコピーがある可能性があり、ビルドを取得するのに時間がかかる可能性があることです。ビルドが機能するまでに数時間かかる可能性があります。つまり、その間、他の誰もファイルを作成して名前を変更することはできません。

正しい解決策は、マージ可能なモデルに切り替えることだと私は反論します。「レネゲードファイル」の問題に対する私の答えは、それは貧弱なプログラマーの規律の問題であり、貧弱な規律の修正として弱いプログラマーの選択を使用するべきではないということです。代わりに、プログラマーの規律の欠如を修正するための行動を取る必要があります。

それで、誰が正しいのですか？チェックインしていますか-反逆ファイルの問題に対する正当な回答を確認してください？それとも、この.csproj問題は複数の開発者にとって非常に面倒な問題ですか？または、Sourcegearが間違っていて、csprojファイルを更新およびマージするように設定しても問題ありませんか？

4

6 に答える 6

5

あなたたちが遭遇した更新とマージの問題は、あなたのグループとコンサルティンググループの間のコミュニケーションの欠如、そして問題が何であるかについてのコンサルティンググループからあなたのグループへのコミュニケーションの欠如に根ざしており、必ずしも問題ではありませんバージョン管理メソッド自体を使用します。理想的には、通信の問題を最初に解決する必要があります。

2つのバージョン管理方法の違いに関するテクニカル分析は適切だと思います。また、更新/マージの方が優れていることに同意します。しかし、本当の問題は、グループ内の人々とのコミュニケーションにあると思います。それがバージョン管理の使用でどのように明らかになるか、そしてグループ内の人々がバージョン管理プロセスに乗り込んでいるか、快適であるかどうかです。選択しました。私がこれを言っているように、仕事中の私自身のグループは、VCの代わりにアジャイル/スクラムだけで、まったく同じことを苦労していることに注意してください。それは苦痛で、迷惑で、イライラしますが、（私が思うに）秘訣は根本的な問題を特定して修正することです。

ここでの解決策は、（どのVC方式を選択しても）すべての人に適切に伝達されるようにすることだと思います。これは複雑な部分です。特定のVC手法を使用するチームだけでなく、コンサルティングチームも参加させる必要があります。 。コンサルティングチームの誰かがマージ操作を実行する方法がわからない場合は、それらをトレーニングしてみてください。重要なのは、問題が発生したときに問題を解決できるように、コミュニケーションをオープンで明確に保つことです。

于 2009-09-16T16:59:19.063 に答える
2
  1. 適切なソース管理システム（svn、mercurial、git、...）を使用します
  2. 多くの分岐を行う場合は、svn1.6よりも新しいものを使用しないでください。Mercurial / gitの方がさらに良い解決策になると思いますが、まだそれらを使った実践的な経験はあまりありません。
  3. 人々が常にシステムの同じ部分で作業している場合は、システム設計を検討してください。各ユニットの責任が大きすぎることを示しています。
  4. 決して、1日かそこら以上人々をオフラインにすることを決して受け入れないでください。この規則の例外は非常にまれです。
  5. 話し合う。他の開発者にあなたが取り組んでいることを知らせてください。

個人的には、リポジトリにプロジェクトファイルを置くことは避けたいと思います。しかし、繰り返しになりますが、開発者を1つのツールに固定することは決してありません。代わりに、プロジェクトファイル/メイクファイル/その他を生成するビルドシステムを使用します（CMakeはこれを行うための私のフレーバーです）。

編集：ファイルをロックすることは、病気ではなく症状を修正していると思います。これが習慣になると、開発者は何もしないことになります。

于 2009-09-16T17:00:12.343 に答える
2

私は、更新とマージのモデルを使用して、40人以上の開発者のチームで成功したプロジェクトに取り組んできました。このメソッドを機能させるのは、頻繁なマージです。独立したワーカーはリポジトリから変更を継続的に更新（マージ）し、全員が（基本テストに合格するとすぐに）変更を頻繁にマージします。

頻繁にマージすることは、各マージが小さいことを意味する傾向があり、これは大いに役立ちます。個々のコードベースとリポジトリからの夜間のチェックアウトの両方で頻繁にテストすることは、非常に役立ちます。

于 2009-09-16T17:04:05.733 に答える
0

高度に並列化された環境では、ファイルに対してチェックイン/チェックアウトの制限なしでSubversionを使用しています。私は、反逆ファイルの問題が規律の問題であることに同意します。マージを使用しないことは根本的な問題を解決しません、開発者が他の人の更新の上にコードの彼ら自身の「修正された」コピーをコピーすることを妨げているのは何ですか？

マージはピタですが、ローカルコピーを早期に頻繁にチェックインして更新することで、最小限に抑えることができます。チェックインを破ることに関してあなたに同意します、彼らは避けられるべきです。一方、チェックインされた変更でローカルコピーを更新すると、変更を適切にマージする必要があり、最終的にチェックインしたときにスムーズに処理されます。

.csprojファイルに関して。これらは単なるテキストであり、ファイルがどのように構造化されているかを理解するために時間を費やすと、実際にマージ可能です。維持する必要のある内部参照があります。

プロジェクトのビルドに必要なファイルをバージョン管理から除外する必要があるとは思いません。プロジェクトの一部が記録されていない場合、どうすれば変更を確実に再構築または追跡できますか？

于 2009-09-16T16:49:48.070 に答える
0

私は小さな会社の開発マネージャーで、プログラマーは3人だけです。私たちが取り組んでいるプロジェクトには数週間かかることもあり、ビッグバン、衝撃、畏怖の実装スタイルを採用しています。これは、実装する夜に完全に機能しなければならないデータベースの変更とプログラムの変更がたくさんあることを意味します。私たちはプログラムをチェックアウトし、それを変更して脇に置きます。なぜなら、他のすべての前にそれを実装すると、他の20のことが爆発するからです。私はチェックアウトしてロックします。そうしないと、プログラムにすでに大規模な変更が加えられていることに気付かずに、別の人がいくつかの変更を行う可能性があります。また、マージは、データベースを変更していない場合、またはソース管理下にない他のシステムに変更を加えていない場合にのみ役立ちます。（Microsoft CRM、基本的には構成を通じて拡張可能なパッケージソフトウェア）

于 2010-12-23T22:08:38.323 に答える
-1

IMO、.csprojなどのプロジェクトファイルは、実際にはソースではないため、バージョン管理システムの一部にしないでください。

また、ほぼ確実にマージ可能ではありません。

于 2009-09-16T16:42:32.627 に答える