問題タブ [accurev]

ソース管理に Accurev を使用している人はいますか? (最終的に) StarTeam から Accurev に切り替えます。

私の最初の印象は、GUI ツールが大幅に不足しているということですが、基盤となるエンジンと、ストリームの概念としてのブランチは信じられないほど素晴らしいものです。

私たちが直面している最大の困難は、スターチームと連動する独自の DIY ツールを評価し、それらを新しい DIY ツールに置き換えるか、適切な代替品を見つけて購入することです。

また、問題管理に AccuWork コンポーネントを使用している人はいますか? Starteam には非常に優れた変更要求システムがありましたが、AccuWork はそれに匹敵するものではありません。Accuwork を使用するか、JIRA などのサードパーティ パッケージを購入するかを評価しています。

意見？

コマンド プロンプトから即座に実行される実行可能ファイルがありますが、System.Diagnostics.Process を使用して生成されたときに返されないようです。

基本的に、私は Accurev CLI インターフェイスの周りに .NET ライブラリ ラッパーを書いているので、各メソッド呼び出しは CLI プロセスを生成してコマンドを実行します。

これは、1 つのコマンドを除くすべてのコマンドでうまく機能します。

ただし、これをコンソールから実行すると正常に動作し、.net プロセスを使用して呼び出すとハングします...使用するプロセス生成コードは次のとおりです。

p.WaitForExit() でハングします。

何かアドバイス？

編集：解決しました！

出力バッファがオーバーフローすると .NET プロセスがハングするので、非同期読み取りメソッドを使用するように切り替えたところ、すべてが機能しました。

現在、別の SCM から AccuRev に切り替えています。かなりの数のプロジェクトがあり、AccuRev でそれらを適切にレイアウトする方法に苦労しています。

私はかなりの数の関連プロジェクトを持っており、それらを単一のデポに保持したいと考えていますが、個々のプロジェクトを追跡できるようにそれらを分離する方法がわかりません。つまり、すべてのプロジェクトを一度にプルする必要はありません。

私のプロジェクトのレイアウトは今です

これらのプロジェクトを単一のデポで管理する方法を提案している人はいますか?それとも、複数のデポ (プロジェクトごとに 1 つ) を使用する必要がありますか?

私の質問は、Git がブランチを処理する方法についてです。コミットからブランチするときはいつでも、マージで強制しない限り、このブランチは親ブランチから変更を受け取ることはありません。

しかし、Clearcase や Accurev などの他のシステムでは、ブランチが何らかの継承メカニズムで満たされる方法を指定できます。つまり、Clearcase では config_spec を使用して、「ブランチ /main/issue001 で変更されたすべてのファイルを取得し、次に、/main またはこの特定のベースラインにあるものに進みます。」

Accurev には、ブランチで新しいコミットをマージしたり作成したりせずに、ストリームが上位のブランチから変更を受信できるようにする同様のメカニズムもあります (ストリームは、それらを呼び出す方法です)。

Git を使用していて、これを見逃していませんか? この継承が必須であるシナリオを列挙できますか?

ありがとう

更新実際に私の質問に焦点を当てるには、以下のVonCの回答をお読みください。「線形ストレージ」と DAG ベースの SCM にはさまざまな機能があることに同意したら、私の質問は次のとおりです。 (特に OSS よりも多くの企業にとって) 線形が DAG では不可能なことを実行できる実際のシナリオはどれですか? 彼らは価値がありますか？

AccuRevとPerforceのどちらかを決定しようとしています。私たちには小さなチームがあり、学びやすいものが必要です。これらのバージョン管理アプリケーションのうち、習得が容易でユーザーフレンドリーなものはどれですか？

AccuRev でファイルの履歴を (「履歴モード」で) 見ると、ファイルに対して実行されたアクションのリストが表示されます。各アクションには番号 (#) とバージョンがあります。

これらのアクションの 1 つをクリックすると、別のリストが表示され、そのアクションに関与した各ファイルが表示されます (履歴を調査しているファイルも含まれます)。この下部パネルの各エントリには、「仮想バージョン」と「実際のバージョン」があります。

上部パネルの「バージョン」は、下部パネルの私のファイルの「仮想バージョン」と同じように見えます。

バーチャル版とリアル版の # の違いは何ですか? 仮想バージョンと実際のバージョンにスラッシュで区切られた 2 つの数字があるのはなぜですか?

最近、64ビットバージョンのXPを新しい開発マシンにインストールし、続いてAccuRevをインストールしました。私が気づいたことの1つは、以前にACCUREV_IGNORE_ELEMS環境変数の32ビットマシンで使用した無視ルールが適用されていないことです。

他の誰かがこれに遭遇しましたか？

Accurevの現在のバージョン (4.7) でのパフォーマンスはどうですか?

• 100 MB あたり、GB あたりのチェックアウト時間は?
• ファイル数または MB あたりのコミット時間は?
• 100以上のストリーム時のGUIの応答性?

Accurev のデモを行ったところですが、ストリームは、コード/プロジェクトに関するワークフローをモデル化するための軽量な方法のように見えます。Accurev のストリーム バックエンドを称賛し、パフォーマンスに不満を持っている人がいるのを聞いたことがあります。Accurev はパフォーマンスに取り組んでいるように見えますが、実世界のデータを取得して、デモがうまく実行されていないことを確認したいと思います。

Accurev のパフォーマンスの逸話や (さらに良い) テストのデータを持っている人はいますか?

現在選択されているディレクトリ内のすべての「古い」ファイルを検索/表示することは可能ですか? 注意: コマンド ラインではなく acgui ツールを使用しています。

AccuRev 用の AccuBridge プラグインを使用しています。このプラグインは、差分を実行するために acdiffgui ツールを使用します。acdiffgui ツールは、/usr/bin にシンボリック リンクとして存在します。

acdiffgui -> /opt/accurev/bin/acdiffgui

これは Eclipse 内で正常に機能します。2 つのファイルを問題なく比較できます。ただし、acdiffgui ツールはかなり制限されているため、代わりに Meld を使用したいと考えています。

プラグイン自体からこれを構成する方法がないため、シンボリック リンクを更新して、meld ツールを指すようにしました。

acdiffgui -> /usr/bin/meld

2 つのファイルを比較しようとしても、何も起こらず、エラーも発生しません。したがって、Eclipse の出力を調べて、何が問題なのかを示す兆候があるかどうかを確認したいと思います。

/.metadata/.log ファイルを見ましたが、エラーは表示されません。これは正しい場所ですか? もしそうなら、ログレベルを上げる方法はありますか?

他の提案は大歓迎です。