30

私はgit、Subversion、CVS、その他の無数のソース管理システムを理解しています。

私はAccurevを使い始めましたが、それは私を混乱させます。

他のSCMと関連付けるメンタルモデルを形成する必要があると思います。私はgitを最もよく理解しているので、理想的にはgitに関連しています。

私はgitを「コミットがdiff、親（または複数の親）ハッシュ、およびそれ自体のハッシュであるコミットの有向グラフ」として説明します。そこから簡単に進んで、リベースや実際のマージとは何か、早送りと実際のマージなどの概念を説明できます。新しいユーザーに複雑なgitの概念を約15〜20分で教えるのは簡単だと思いました。

そのレベルでAccurevを本当に理解したいと思います。それで...

Accurevがどのように動作するかを説明できるようにする、Accurevの動作の1文の抽象化とは何ですか？

メンタルモデルに答えてもらいたい質問の例：

  • 一部のファイルを「保持」してから「プロモート」するとどうなりますか？
  • 保存したファイルと同じファイルをプロモートしないとどうなりますか？
  • 競合しない（重複する）更新が発生したときに、履歴の属性が誤って表示されることがあるのはなぜですか？これは特に、Subversionの障害モードを彷彿とさせます。私が聞いた基本的な説明から、Accurevには存在すべきではないと思います。
  • なぜdiffには、私が期待するものがほとんど含まれていないのですか？何が起こっているのかというと、基本に対する差分が現在の（移動中の）親ストリームに対する差分を示していると思いますが、私が本当に望んでいるのは、最後に更新してから行った変更を確認することだけです。
4

5 に答える 5

27

免責事項：私が最もよく理解しているソース管理システムはSVNです。これにより、レポやチェックアウトなどの用語の使用法が色付けされます。また、私は日常的にAccurevを使用していますが、しっかりと把握しているコアコンセプトから遠く離れることはありません。

1つの文（アスタリスク付き）： Accurevは、ストリーム/ワークスペースごとに変更されたファイルの改訂履歴を保持し、各ストリームが透過的に更新されている間に（ストリーム内の）異なるバージョンのコードを開発できるようにする時系列のリポジトリです。親および子*ストリームからのコアコード。

（*）子ストリームが親ストリームへの変更をプロモートした場合にのみ、子ストリームによってストリームが更新されます。

Accurevの主な利点は、さまざまなバージョンのコードを簡単に維持できることです。あなたがそれを理解したいのであれば、私はあなたが精通している言語で再定義された簡単な抽象化や用語を探しません。例と用語の穏やかな説明を探します。残念ながら、私は自分が知る必要があることしか知りませんが、それを試してみます...

（後でワークスペースに移動します。この時点では心配しないでください。）

あるストリームを別のストリームから親として作成する場合、SVNブランチを作成して子ストリームを作成したようなものですが、（すばらしい）違いは、親ストリームまたは子ストリームを更新するたびにSVNマージが処理されることです（または競合が存在する場合はアラートが表示され、手動で解決する必要があります）。

ストリームCompanyStreamから始めたとしましょう。コードベースはそのストリームによって管理され、ファイルに加えた変更の履歴があります。次に、その下に2つの子ストリームChildStream1、ChildStream2を作成することにします。CompanyStream内のファイルに加えられた変更は、両方の子ストリームに細流化されるため、CompanyStreamから継承した最新のコードが常に含まれます。（リビジョン変更の継承はAccurevの主要な概念です。）一方、ChildStream1で1つのベンダーに固有の開発を行っており、ChildStream2で別のベンダーに固有の変更を行っています。ChildStream1と2のどのコードをCompanyStreamにプロモートするかを選択的に決定できますが、CompanyStreamで行われた変更は、両方の子ストリームに表示する必要があります。

ストリームの視覚化は次のようになります。

CompanyStream-
                            |-ChildStream1
                            |-ChildStream2

Accurev Overlap =ストリームを更新してから、親ストリームのファイルが変更されました。親ストリームが自分の上にあることを視覚化し（これがクライアントに表示される方法です）、そのストリームは水平方向に進行しているため、現在の時点と重なっています。

SVNからAccurevの概念へのクイックマッピング：
SVNチェックイン-SVNチェックアウトのプロモート
-アンカー（何かを固定するとWIPになります-作業中）
SVN更新-更新

Accurevワークスペース

ワークスペースについてはまだ触れていません。ワークスペースは、ハードドライブ上のコードを表します。ワークスペースは、履歴を持つことができ、行った変更を追跡できるという点でストリームに似ています。（これはKeepの機能です。Keep操作中に指定したファイルのスナップショットをワークスペースの履歴に保存します。これらのファイルのスナップショットにいつでも戻すことができます。その結果、ワークスペースを次のように表示することもできます。独自のプライベートストリーム。これは、内部のコードに加えられた変更の記録です。）

ストリームは、リビジョンの変更と何が起こったかの履歴を表す抽象的な概念です。ストリームとワークスペースは、親ストリームからコードを継承します。ただし、ストリームとは異なり、ワークスペースに子ストリームまたは子ワークスペースを含めることはできません。ワークスペースは木の上の葉のようなものです。ストリームは枝のようなものです。

  • 一部のファイルを「保持」してから「プロモート」するとどうなりますか？

ストリームにプロモートします。あなたはワークスペースにとどまります。プロモートされた変更は、ストリームを表示できるすべての人に表示されます。保持された変更は、ワークスペースの所有者であるあなただけに表示されます。

Keptファイルには、ワークスペースにスナップショットがあります（それらに戻したい場合に備えて）。プロモートされたファイルには、プロモートされたストリームに（いわば）スナップショットが含まれます。大きな違いは、プロモートされた変更が、そのストリームを継承するすべてのストリームまたはワークスペースにトリクルダウンすることです。

  • 保存したファイルと同じファイルをプロモートしないとどうなりますか？

その後、それらはあなたのワークスペースにのみ存在します。また、プロモートを実行すると、Accurevが最初にキープを実行すると思います（したがって、ワークスペースとプロモート先のストリームの両方でファイルの変更の記録があります）。

  • 競合しない（重複する）更新が発生したときに、履歴の属性が誤って表示されることがあるのはなぜですか？これは特に、Subversionの障害モードを彷彿とさせます。私が聞いた基本的な説明から、Accurevには存在すべきではないと思います。

例を挙げていただけますか？Accurevのファイルバージョン管理についての私の理解は少し曖昧です。バージョン属性は、最新の変更がプロモートされた（保持されていない）ワークスペースまたはストリームによって割り当てられると思います。いくつかのストリーム継承関係があり、ファイルをトレースするまで正しくないように見える属性がファイルに含まれている可能性があります。

  • なぜdiffには、私が期待するものがほとんど含まれていないのですか？何が起こっているのかというと、基本に対する差分が現在の（移動している）親ストリームに対する差分を示していると思いますが、私が本当に望んでいるのは、最後に更新してから行った変更を確認することだけです。

次に、ベーシスに対してではなく、「バック」に対して差分を実行します。

私にとって有効な単純な構成は次のとおりです。私は常に、いくつかのパブリック開発ストリームから独自のプライベートストリームを作成します。次に、チェックインしたい（または元に戻せるようにする）変更を加えると、自分のストリームにプロモートします。私は自分のワークスペースで作業を続けています。自分のワークスペースを以前に行ったことや自分の上で起こっていること（他の人が行った変更）と比較したい場合は、Backedと比較します。

申し訳ありませんが、これはとても長いです。うまくいけば、それが役立つ...

于 2011-01-18T15:28:04.183 に答える
7

他の何人かがあなたの直接の質問に答えようとしたので-デイブの答えが最も簡潔で正確です-私はあなたの弾丸を突き刺します：

  • 一部のファイルを「保持」してから「プロモート」するとどうなりますか？

    ファイルを保持すると、そのファイルの新しいバージョンが作成されますが、ワークスペース専用です。自律的なコーディング、迂回ポイントの作成、単なるプライベート開発に最適です。将来いつでも、自分自身または他の寄稿者のいずれかから、以前に保持されていたバージョンのファイルに戻すことができます。現在のバージョン（コンパイル、ビルド、テストなど）に慣れたら、それを親ストリームにプロモートできるため、コミットしたときにできることを壊すリスクなしに、他のユーザーを自分のバージョンに公開できます。チェックイン時に。

  • 保存したファイルと同じファイルをプロモートしないとどうなりますか？

    繰り返しますが、完全なワークスペースの自律性。あなたが自分のしていることを追跡できるような開発者であれば、一度に100個のファイルを処理できます。どれも、すべて、1つ、一部を宣伝することはできますが、実際には問題ではありません。これは、タイムラインで行うことができます。

  • 競合しない（重複する）更新が発生したときに、履歴の属性が誤って表示されることがあるのはなぜですか？これは特に、Subversionの障害モードを彷彿とさせます。私が聞いた基本的な説明から、Accurevには存在すべきではないと思います。

    あなたがここで何を指しているのか具体的にはわかりません。AccuRevワークスペースで更新を実行すると、進行中の作業が上書きされることはありません。継承される要素（つまり、親階層のコンテンツが変更された要素）で作業している場合、それらはワークスペースに（重複）としてリストされます。繰り返しになりますが、いつマージを実行するかを選択し、それでも上記から他の変更を更新し、競合しているファイルで作業を続けることもできます。マージは、プロモート時とは対照的に、ワークスペースで行われ、他の場所に配信する前に、結果をもう一度コンパイル、ビルド、テストするオプションを提供します。

  • なぜdiffには、私が期待するものがほとんど含まれていないのですか？何が起こっているのかというと、基本に対する差分が現在の（移動中の）親ストリームに対する差分を示していると思いますが、私が本当に望んでいるのは、最後に更新してから行った変更を確認することだけです。

    ベーシスに対する差分は、ワークスペース内のバージョンが、更新またはワークスペースの作成から最後に継承したバージョンとどのように比較されるかを示します。Backedに対する差分は、バージョンが現在親ストリームにあるものとどのように比較されるかを示します。したがって、進行中のファイルに対して誰かがそのファイルへの変更をプロモートした場合、Diff Against Basisは元のファイルとのみ比較され、DiffAgainstBackedは親の新しいコンテンツと比較されます。ちなみに、[履歴]-> [バージョンの参照]ビューでは、ファイルの任意の2つのバージョンを相互に比較できます。

うまくいけば、これはあなたの特定の質問についての少しの見通しを提供します。

于 2011-01-07T21:01:33.460 に答える
3

AccurevはClearCaseから派生し、ClearCaseUCMストリームの後に取得します。
（AccurevモデルはUCMといくつかの類似点があり、以前のClearCaseユーザーに好評です）

ストリームは構成です。つまり、作業（コンパイル、テスト、デバッグなど）する必要のあるラベル（読み取り専用コンポーネントの場合）またはファイル（書き込み可能コンポーネントの場合）のリストです。

そのため、AccurevはSCMのストリームベースのアーキテクチャとして提供されています。

開発者ごとに1つのプライベートストリーム（ワークスペースストリーム）があり、そこからより一般的なストリームにプロモートできます。各プロモーションは、親ストリームの構成（これも作業する必要があるもののリストにすぎません）を更新します。

于 2011-01-07T06:43:48.010 に答える
3

私はgitを「コミットがdiff、親（または複数の親）ハッシュ、およびそれ自体のハッシュであるコミットの有向グラフ」として説明します。

gitリポジトリは、FWIW、履歴ツリーのフォレストであり、コミットリーフは（コミットメタデータに加えて）ディレクトリとファイルのツリーです。少なくともコンセプトに関しては、Gitではなく、相違はありません。ストレージエンジンがたまたま削除を行う場合、それは別の話です。

AccuRevについては、2分間の紹介ビデオ（広告ではなく参照用のリンク）を視聴しました。これは、平均的な時間調整されたSCM履歴ツリー（ブランチ）とほとんど同じです。水っぽい波のアイコンが付いているアイテムはブランチヘッドで、黄色のフォルダーのようなものは作業用コピーです。プレゼンターが作業コピーを移動するとき、彼は部下のすべての作業コピーのリベースを行っているようです（これは悪いことです！マージの競合について考えてみてください！）。3つの緑色の点が付いたアイコン（問題リスト）はコミットリストになり、コピーするとチェリーピックされます。

一言で言えば、cvs / svn / gitの経験を通して、あなたがまだ知らないことは何もありません—私が言うに沿って進んでください。

于 2011-01-07T00:18:16.473 に答える
1

Qのスタイルに基づいて、技術的な（ビジネス以外の）一文を提供します。

AccuRevは、s/w構成のモデリングにオブジェクト指向のアプローチを採用しています。とてもシンプルで素晴らしいです！特に、ワ​​ークフローをモデル化している場合、またはそれ以上の場合は、継続的デリバリーを設定します（別のトピック）。しかし、私はそう見てきました。多くの人がこの強力なテクノロジーとデータモデルのアプローチを却下しています。なぜなら、従来の「ブランチ」ala cvs、svn、p4、cc、adinfinitumを超えて見ることができないからです。最良の例えは、一連のAccuRevストリームをクリアケースの構成仕様のルールと比較することです...（注：これは単なる例えです）が、ストリームは時間ベースの構成と履歴を維持するファーストクラスのエンティティであるため、はるかに強力です。

AccuRevを理解する秘訣は、特定の「ストリーム」が完全な構成を表す（つまり、チェックアウトできる）一方で、そのストリームの実際の内容は、ローカルファイル/ディレクトリの変更、からの変更を集約することによって動的に決定されることです。親、残りのファイルが収集される最上部までツリーを上に移動します。したがって、ストリームの「ツリー」が表示されるときはいつでも、それらはブランチではありません...むしろ、トップストリームが「スーパークラス」のようであり、すべての[孫]子が[サブ]サブクラスである一連の継承ベースの構成です。新しいファイル/ディレクトリの変更は、開発、統合、QAなどから進むにつれてツリーの上位に昇格します。

HTH_デイブ

于 2011-01-07T05:36:18.413 に答える