1

私は、米国とヨーロッパの両方に開発チームを持つ会社で働いています。現在、各施設で Perforce を使用しており、共同で新しいシステムを構築する予定です。私は分散型チームなので、git または Mercurial に移行することを強く望んでいますが、同僚は慎重です。彼らは Perforce を気に入っており、DVCS に移行するメリットを感じていません。

納得させる正当な理由を思いつくのに苦労していることを認めざるを得ません。2 つの施設間の高速回線は、中央の Perforce リポジトリを使用するか、施設ごとに 1 つのクローンを作成できることを意味します。

発生した懸念は、1 つのマスター リポジトリが存在しないことです。開発者は、チェックアウトしたばかりのコードが最新であるかどうかを知ることはできません。他の誰かが同じファイルを更新しているとしますか?

はい、私は git/Mercurial 初心者です。議論の余地のない理由で私を助けてくれる人はいますか?

ありがとう！

4

3 に答える 3

4

切り替える理由がわからない場合は、なぜ切り替えたいのですか?

人々は、perforce に欠けている git の機能を好きなように提供できますが、「ローカル リポジトリは履歴の高速化を意味します!」、「git bisect なしでは生きていけない」、「perforce には stash がないため、個別のユニットをチェックインするのが難しい!」.. . あなたの会社にとって git が perforce よりも優れている点を誰も教えてくれません。

ですから、こう自問してみてください。そして、「perforce が強制している制限がなければ、何が改善できるでしょうか?」。これらの質問に答えたら、git が役立つかどうかを確認してください。本当の質問をした後、「反論しにくい理由」はあなたの手の中にあり、実際の同僚に適用されます。

于 2012-07-06T15:23:08.327 に答える
2

あなたの質問は、集中型 VCS と分散型 VCS ほど git/mercurial に関するものではないようです:

  1. 分散型 VCS - 長所
    • ソースの複数のコピー; サーバーがダウンした場合、複数のワークステーションからコードを利用できます
    • ローカル コピーは、更新がより小さくなり、ネットワーク集約的でなくなる傾向があることを意味します
  2. 分散型 VCS - 短所
    • 変更の同期; チェックイン率が高く、複数のスタッフが同じモジュールで作業している場合は、プッシュ/プル/マージのための非常に明確なプロトコルが必要です
  3. 一元化されたVCS - 長所
    • コードのための 1 つの場所 - どのリポジトリが正規であるか、または正規である必要があるかを知っています
  4. 集中型 VCS - 短所
    • コード用の 1 つの場所 - サーバーが利用できないということは、開発者がブランチやバージョンを長期間問題なく使用できないことを意味します。
于 2012-07-06T16:00:14.503 に答える
0

質問に答えるために、「集中型の VCS から分散型の VCS に移行することが合理的なシナリオを思いつく人はいますか?」はい、できます：

  • 開発チームは非常に疎結合です。彼らは独立したスケジュール、管理、基準などを持っています。彼らは非常に独立しているため、CVCSは彼らにとって官僚的な官僚主義にすぎません。
  • 彼らが行う開発は、監査やコンプライアンス基準の対象ではありません。誰がいつ何をしたかという中心的な記録がなくても、会社にとって問題にはなりません。
于 2012-07-06T18:38:24.920 に答える