Accurevがどのように機能するかについての1文の説明は何ですか？
私はgit、Subversion、CVS、その他の無数のソース管理システムを理解しています。
Accurevを使い始めましたが、混乱します。
他のSCMと関連付けるメンタルモデルを形成する必要があると思います。私はgitを最もよく理解しているので、理想的にはgitに関連しています。
Gitは、「コミットがdiff、親（または複数の親）ハッシュ、およびそれ自体のハッシュであるコミットの有向グラフ」として説明します。そこから簡単に進んで、リベースや実際のマージとは何か、早送りと実際のマージなどの概念を説明できます。新しいユーザーに複雑なgitの概念を約15〜20分で教えるのは簡単だと思いました。
そのレベルでAccurevを本当に理解したいと思います。そう...
Accurevがどのように動作するかを説明できるようにする、Accurevの動作の1文の抽象化とは何ですか？
メンタルモデルに答えてもらいたい質問の例：
- 一部のファイルを「保持」してから「プロモート」するとどうなりますか？
- 保存したファイルと同じファイルをプロモートしないとどうなりますか？
- 競合しない（別名重複する）更新が発生したときに、履歴の属性が誤って表示されることがあるのはなぜですか？これは特に、Subversionの障害モードを彷彿とさせます。私が聞いた基本的な説明から、Accurevには存在すべきではないと思います。
- なぜdiffには、私が期待するものがほとんど含まれないのですか？何が起こっているのかというと、基本に対する差分が現在の（移動中の）親ストリームに対する差分を表示していると思いますが、本当に欲しいのは、最後に更新してから行った変更を確認することだけです。
免責事項：私が最もよく理解しているソース管理システムはSVNです。これにより、レポやチェックアウトなどの用語の使用法が色付けされます。また、私は日常的にAccurevを使用していますが、しっかりと把握しているコアコンセプトから遠く離れることはありません。
1文（アスタリスク付き）: Accurevは、ストリーム/ワークスペースごとに変更されたファイルの改訂履歴を保持し、（ストリーム内の）異なるバージョンのコードを開発できるようにする時系列のリポジトリです。一方、各ストリームは、その親ストリームと子*ストリームのコアコードで透過的に更新されます。
（*）子ストリームが親ストリームへの変更をプロモートした場合にのみ、子ストリームによってストリームが更新されます。
Accurevの主な利点は、さまざまなバージョンのコードを簡単に維持できることです。あなたがそれを理解したいのであれば、私はあなたが精通している言語で再定義された簡単な抽象化や用語を探しません。例と用語の穏やかな説明を探します。残念ながら、私は自分が知る必要があることしか知りませんが、それを試してみます...
（後でワークスペースに移動します。この時点では心配しないでください。）
あるストリームを別のストリームからペアレント化して作成する場合、SVNブランチを作成して子ストリームを作成したのと同じですが、（すばらしい）違いは、親ストリームまたは子ストリームを更新するたびにSVNマージが処理されることです（または競合が存在する場合は警告が表示され、手動で解決する必要があります）。
ストリームCompanyStreamから始めたとしましょう。コードベースはそのストリームによって管理され、ファイルに加えた変更の履歴があります。次に、その下に2つの子ストリームChildStream1、ChildStream2を作成することにします。 CompanyStream内のファイルに加えられた変更は、両方の子ストリームに細流化されるため、CompanyStreamから継承した最新のコードが常に保持されます。 （リビジョン変更の継承はAccurevの主要な概念です。）一方、ChildStream1のあるベンダーに固有の開発を行っており、ChildStream2の別のベンダーに固有の変更を行っています。 ChildStream1と2のどのコードをCompanyStreamにプロモートするかを選択的に決定できますが、CompanyStreamで行われた変更は、両方の子ストリームに表示する必要があります。コードをChildStream1からCompanyStreamにプロモートする場合、更新を行うと、それらの変更はChildStream2に表示されます（これもCompanyStreamを継承するため）
ストリームの視覚化は次のようになります。
CompanyStream-
| -ChildStream1
| -ChildStream2
Accurev Overlap =ストリームを更新してから、親ストリームのファイルが変更されました。親ストリームが自分の上にあることを視覚化し（これがクライアントに表示される方法です）、そのストリームは水平方向に進行しているため、現在の時点と重なっています。
SVNからAccurevの概念へのクイックマッピング：
SVNチェックイン-プロモート
SVNチェックアウト-アンカー（何かを固定すると仕掛品になります-作業中）
SVNアップデート-アップデート
Accurevワークスペース
ワークスペースについてはまだ触れていません。ワークスペースは、ハードドライブ上のコードを表します。ワークスペースは、履歴を持つことができ、行った変更を追跡できるという点でストリームに似ています。 （これはKeepが行うことです。Keep操作中に指定したファイルのスナップショットをワークスペースの履歴に保存します。いつでもそれらのファイルスナップショットに戻すことができます。その結果、ワークスペースを自分のワークスペースとして表示することもできます。独自のプライベートストリーム。これは、内部のコードに加えられた変更の記録です。）
ストリームは、リビジョンの変更と何が起こったかの履歴を表す抽象的な概念です。ストリームとワークスペースは、親ストリームからコードを継承します。ただし、ストリームとは異なり、ワークスペースに子ストリームまたは子ワークスペースを含めることはできません。ワークスペースは木の上の葉のようなものです。ストリームは枝のようなものです。
- 一部のファイルを「保持」してから「プロモート」するとどうなりますか？
ストリームにプロモートします。あなたはワークスペースにとどまります。プロモートされた変更は、ストリームを見ることができるすべての人に表示されます。保持された変更は、ワークスペースの所有者であるあなただけに表示されます。
Keptファイルには、ワークスペースにスナップショットがあります（それらに戻したい場合に備えて）。プロモートされたファイルには、プロモートされたストリームに（いわば）スナップショットが含まれます。大きな違いは、プロモートされた変更が、そのストリームを継承するストリームまたはワークスペースに細流化することです。
- 保存したファイルと同じファイルをプロモートしないとどうなりますか？
その後、それらはあなたのワークスペースにのみ存在します。また、プロモートを実行すると、Accurevが最初にキープを実行すると思います（したがって、ワークスペースとプロモート先のストリームの両方でファイルの変更の記録があります）。
- 競合しない（別名重複する）更新が発生したときに、履歴の属性が誤って表示されることがあるのはなぜですか？これは特に、Subversionの障害モードを彷彿とさせます。私が聞いた基本的な説明から、Accurevには存在すべきではないと思います。
例を挙げていただけますか？ Accurevのファイルバージョン管理についての私の理解は少し曖昧です。バージョン属性は、最新の変更がプロモートされた（保持されていない）ワークスペースまたはストリームによって割り当てられると思います。いくつかのストリーム継承関係があり、ファイルをトレースするまで正しくないように見える属性がファイルに含まれている可能性があります。
- なぜdiffには、私が期待するものがほとんど含まれないのですか？何が起こっているのかというと、基本に対する差分が現在の（移動中の）親ストリームに対する差分を表示していると思いますが、本当に欲しいのは、最後に更新してから行った変更を確認することだけです。
次に、ベーシスに対してではなく、「バック」に対して差分を実行します。
私にとって有効な単純な構成は次のとおりです。私は常に、いくつかのパブリック開発ストリームから独自のプライベートストリームを作成します。次に、チェックインしたい（または元に戻せるようにする）変更を加えると、自分のストリームにプロモートします。私は自分のワークスペースで作業を続けています。自分のワークスペースを以前に行ったことや自分の上で起こっていること（他の人が行った変更）と比較したい場合は、Backedに対して差分を取ります。
申し訳ありませんが、これはとても長いです。うまくいけば、それが役立つ...
他の何人かがあなたの直接の質問に答えようとしたので-デイブの答えが最も簡潔で正確です-私はあなたの弾丸を突き刺します：
一部のファイルを「保持」してから「プロモート」するとどうなりますか？
ファイルを保持すると、そのファイルの新しいバージョンが作成されますが、ワークスペース専用です。自律的なコーディング、迂回ポイントの作成、単なるプライベート開発に最適です。将来いつでも、自分自身または他の寄稿者から、以前に保持されていたバージョンのファイルに戻すことができます。現在のバージョン（コンパイル、ビルド、テストなど）に慣れたら、それを親ストリームにプロモートできるため、コミットしたときにできることを壊すリスクなしに、他のユーザーを自分のバージョンに公開できます。チェックイン時に。
保存したファイルと同じファイルをプロモートしないとどうなりますか？
繰り返しますが、完全なワークスペースの自律性。あなたが自分のしていることを追跡できるような開発者であれば、一度に100個のファイルを処理できます。どれも、すべて、1つ、一部を宣伝することはできますが、実際には問題ではありません。これはタイムラインで行うことができます。
競合しない（別名重複する）更新が発生したときに、履歴の属性が誤って表示されることがあるのはなぜですか？これは特に、Subversionの障害モードを彷彿とさせます。私が聞いた基本的な説明から、Accurevには存在すべきではないと思います。
あなたがここで何を指しているのか具体的にはわかりません。 AccuRevワークスペースで更新を実行すると、進行中の作業が上書きされることはありません。継承される要素（つまり、親階層のコンテンツが変更された要素）で作業している場合、それらはワークスペースに（重複）としてリストされます。繰り返しになりますが、いつマージを実行するかを選択し、それでも上記から他の変更を更新し、競合しているファイルで作業を続けることもできます。マージはプロモート時ではなくワークスペースで行われ、他の場所に配信する前に結果をもう一度コンパイル、ビルド、テストするオプションを提供します。
なぜdiffには、私が期待するものがほとんど含まれないのですか？何が起こっているのかというと、基本に対する差分が現在の（移動中の）親ストリームに対する差分を表示していると思いますが、本当に欲しいのは、最後に更新してから行った変更を確認することだけです。
ベーシスに対する差分は、ワークスペース内のバージョンが、更新またはワークスペースの作成から最後に継承したバージョンとどのように比較されるかを示します。 Backedに対する差分は、バージョンが現在親ストリームにあるものとどのように比較されるかを示します。そのため、進行中のファイルの変更を誰かがプロモートした場合、Diff Against Basisは元のファイルとのみ比較され、Diff AgainstBackedは親の新しいコンテンツと比較されます。ちなみに、[履歴]-> [バージョンの参照]ビューでは、ファイルの任意の2つのバージョンを相互に比較できます。
うまくいけば、これはあなたの特定の質問について少し見通しを提供します。
Accurevは ClearCaseから派生 であり、 ClearCase UCMストリーム の後になります。
（AccurevモデルにはUCMといくつかの類似点があり、 以前のClearCaseユーザーに好評 ）
ストリームは構成であり、作業（コンパイル）する必要のあるラベル（読み取り専用コンポーネントの場合）またはファイル（書き込み可能コンポーネントの場合）のリストです。 、および/またはテスト、および/またはデバッグ、...）。
そのため、AccurevはSCMのストリームベースのアーキテクチャとして表示されます。
開発者ごとに1つのプライベートストリーム（ワークスペースストリーム）があり、そこからより一般的なストリームにプロモートできます。プロモーションごとに、親ストリームの構成（これも作業に必要なもののリストにすぎません）が更新されます。
Gitは、「コミットがdiff、親（または複数の親）ハッシュ、およびそれ自体のハッシュであるコミットの有向グラフ」として説明します。
Gitリポジトリは、FWIW、履歴ツリーのフォレストであり、コミットリーフは（コミットメタデータと）ディレクトリとファイルのツリーです。 少なくとも概念に関しては、Gitではなくdiffはありません。ストレージエンジンがたまたま削除を行った場合、それは別の話です。
AccuRevについては、 2分間の紹介ビデオ （広告ではなく参照用のリンク）を視聴しました。これは、平均的な時間調整されたSCM履歴ツリー（ブランチ）とほとんど同じです。水っぽい波のアイコンが付いているものは枝頭で、黄色いフォルダーのようなものは作業コピーです。プレゼンターが作業コピーを移動するとき、彼は部下のすべての作業コピーのリベースを行っているようです（それは悪いことです！マージの競合について考えてください！）。 3つの緑色の点が付いたアイコン（問題リスト）はコミットリストになり、コピーするとチェリーピックされます。
一言で言えば、cvs/svn/gitの以前の経験からは、まだわからないことは何もありません。
Qのスタイルに基づいて、技術的な（ビジネス以外の）一文を提供します。
AccuRevは、s/w構成のモデリングにオブジェクト指向アプローチを採用しています。それはとてもシンプルで素晴らしいです！特に、ワークフローをモデル化している場合、またはそれ以上の場合は、継続的デリバリーを設定します（別のトピック）。しかし、私はそう見てきました。多くの人が、この強力なテクノロジーとデータモデルのアプローチを却下しています。なぜなら、従来の「ブランチ」ala cvs、svn、p4、cc、adinfinitumを超えて見ることができないからです。最良の例えは、一連のAccuRevストリームをクリアケースの構成仕様のルールと比較することです...（注：これは単なる例えです）が、ストリームは時間ベースの構成と履歴を維持するファーストクラスのエンティティであるため、はるかに強力です。
AccuRevを理解する秘訣は、特定の「ストリーム」が完全な構成を表す一方で（つまり、チェックアウトできる）、そのストリームの実際の内容は、ローカルファイル/ディレクトリの変更、からの変更を集約することによって動的に決定されることです。親、残りのファイルが収集される最上部までツリーを上に移動します。したがって、ストリームの「ツリー」が表示される場合は常に、それらはブランチではありません...むしろ、トップストリームが「スーパークラス」のようであり、すべての[孫]子が[サブ]サブクラスである一連の継承ベースの構成です。新しいファイル/ディレクトリの変更は、開発、統合、QAなどから進むにつれてツリーの上位に昇格します。
HTH_デイブ