2

バージョン管理システム（vcs。）としてMercurialをうまく使用している大企業（できればハードウェア）を知っていますか？

私はsvn/cvs/perforceと少しのgitの経験があります。内部政治は私たちをcvsに向かって押し進めていますが、これは悪い選択だと思います。

PERFORCEが一番好きな理由：

  1. 戦闘はハードウェア企業でテストされました。
  2. 大きなバイナリをうまく処理します。
  3. 10Gを超える大規模プロジェクトを非常にうまく処理します。
  4. シンボリックリンクを非常に賢明に処理します。
  5. アトミックチェックインを提供します。
  6. 柔軟な分岐メカニズム。
  7. マージツールはうまく機能しているようです。
  8. ユーザーは管理コマンドを使用する必要はありません。

CVSが好きではない理由：

  1. アトミックチェックインはサポートしていません。
  2. データベースが壊れる可能性があります。
  3. ユーザーエラーを修正するために管理コマンドが必要になる場合があります。

私がCVSが好きな理由：

  1. 戦闘テスト済み。
  2. ほとんどの人は少なくとも少しはそれに精通しています。
4

1 に答える 1

4

あなたが正しい。CVSは悪い選択です。アトミックチェックの欠如は、私の本でそれを失格にするのに十分です。人々はそれを知っていて、何が悪いのか理解していないので、それが好きです。

ハードウェア会社とソフトウェア会社のシステムの使用の唯一の違いは、RTLモジュールが非常に明確に定義されたインターフェースを持ち、通常は1人が所有するため、開発が非常に細分化されていることです。分岐の必要性が減るので、これは実際には集中型システムで非常にうまく機能します。開発者はお互いのつま先をあまり踏みつけません。

あるハードウェア会社がMercurialを試しているのを見たことがありますが、それはめちゃくちゃでした。それが間違ったツールだったわけではありませんが、彼らはCVSの考え方を持っていて、それをCVSのように機能させようとしました。私はここにかなり怒りっぽいアカウントを書きました。

個人的には、SVNは、特にCVSから来る人々にとって、ハードウェア開発に非常に適していると思います。サブツリーをチェックアウトする機能も役立ちます。とは言うものの、私は現在、SVNで「機能ブランチ」ワークフローを作ろうとしている場所で働いており、マージには多くの落とし穴があります。彼らは将来git/hgについて考えています。しかし、彼らは小さな進歩的な会社です。

CVSからMercurialに移行した会社は、Perforceに移行しました。彼らにとって、それはすべてサポート契約と誰かに責任を負わせることでした。ユーザーにとって....まあ....それはユーザーにとって非常に複雑な前線を示していると思います。ワークスペースの概念全体はやり過ぎであり、ブランチ管理は苦痛でした。システムとしては可能ですが、多くの作業を使用する必要があります。

Mercurialを別のハードウェア会社に導入する場合は、サブリポジトリを多用します。これを行うと、サブバージョンからサブツリーのチェックアウトの有用な部分を取り戻すことができます。つまり、RTLモジュールをチェックアウトして、個別に分岐させることができます。また、すべてのサブモジュールを取り込むプロジェクトとなる統合プロジェクトの概念も得られます。これにより、RTLリリースがRTL開発からある程度切り離され、同じモジュールを使用してさまざまなチップが容易になります。また、モジュールを分離しておくことで、履歴も分離され、モジュールの変更の追跡が容易になります。最後に、他の回答で説明した「数百人の開発者が1つの中央リポジトリにアクセスしてマージレースに参加する」問題を回避します。

于 2012-06-26T13:25:33.247 に答える