FAQ検索結果

検索キーワード:

Qすでに他のソフトウェア構成管理ツール(またはバージョン管理ツール)によって管理されているデータを、ディポに移行するユーティリティはありますか?

A
英語版PERFORCEの場合、Subversion、CVS、VSS、PVCSからの移行ユーティリティ(コンバータ)が 公開されています。
日本語版PERFORCEに対しては、現在のところ、これらのコンバータを公開しておりません。詳しくは、弊社テクニカルサポートまでお問い合わせください。

回答を閉じる

Q大量のファイルであっても、ディポ(リポジトリ)への一括登録は簡単ですか?

A
いったん、クライアントのワークスペースにファイルを格納し、登録するだけですので、 非常に簡単です。

回答を閉じる

Q何人の開発者に対して 1人のシステム管理者が必要ですか?

A
PERFORCEは、OSへの依存が少なくファイルシステムへの依存がないため、システム管理が容易で、 トラブルの発生が非常に少ないツールです。 だからと言って、現実的にシステム管理者が不要ということにはなりませんが、 「ツールの世話」という意味ではシステム管理者の負荷は非常に軽く、 システム管理者は純粋なソフトウェア構成管理(ブランチの方針検討、ラベルの適用、 レポートの作成、ユーザの管理等)に専念できます。 開発システムまたはサブシステムに対して1名のシステム管理者で十分でしょう。

回答を閉じる

Qディポ(リポジトリ)をバックアップする機能はありますか?

A
ディポ全体を(自動的に)バックアップするような機能は、残念ながら提供されていません。 ディポ全体は、ユーザの標準的なツールや手順によってバックアップしてください。
ただし、メタデータを管理しているデータベースの部分については、チェックポイント・ファイルと ジャーナル・ファイルを作成する機能を提供します。これにより、例えば週1回の全体バックアップとは 別に、日々のバックアップは非常に短時間で行うことができ、しかもその際に開発作業をストップさせる 必要はありません。さらに、チェックポイント・ファイルとジャーナル・ファイルからのリストアは非常に簡単です。

回答を閉じる

QQA·C/QA·C++はどのコンパイラに対応していますか。

A
次のメーカーのコンパイラに対応しています。(QA·C/QA·C++の 開発元であるProgramming Research社の情報:アルファベット順)
■ARM
■Analog Devices
■Borland
■Code Warrior
■Cosmic
■Diab
■Fujitsu
■GNU
■Green Hills
■Hewlett Packard
■HiTech
■IAR
■IBM
■Intel
■Keil
■Mercury Computer
■Metrowerks
■Microsoft
■National Instruments
■NEC
■Renesas
■Score
■SDCC
■ST Micro
■Sun Forte
■Tasking
■Texas Instruments
■TriMedia
■Watcom
■WindRiver
これらコンパイラ向け設定は、コンパイラ設定ファイル作成支援ツール(CPG) を用いて生成することができます。 詳しくは、保守ユーザ様向け情報ページ の手順書をご確認ください。

上記以外に、弊社で解析実績のあるコンパイラもあります。 設定ファイルを準備しているものもありますので、 適宜弊社サポートにお問い合わせください。

回答を閉じる

Q「常に直接初期化を使用する(-audi+)」オプションの設定基準を教えてください。 QAC++2.1J以上

A
コンパイラの中には、'T x = e;'という形式でクラスを 宣言した場合に、'T x(e);' と記述されたものと見なして 初期化するものと、'T x; x = e;' と記述されたものと 見なして初期化するものがあります。

お使いのコンパイラが、前者の挙動をする場合は、 「常に直接初期化を使用する(-audi+)」オプション を設定する必要があります。後者の場合は、デフォルト(-audi-)のままにします。

具体的には、お使いのコンパイラが次のソースコードをエラーなく コンパイルできる場合は、-audi+オプションを設定する必要があります。 // Error ==> -audi- (default) // Success ==> -audi+ class A{}; class B { public: B(const A&) {} }; class C { public: C(const B&) {} }; void foo() { A c1; C c2 = c1; // Problem } int main(void) { return 0; }なお、設定方法は次の通りです。

GUIから設定する場合:
  [コンパイラ パーソナリティ] の [拡張] タブで
  [常に直接初期化を使用する]
  チェックボックスを選択します。

設定ファイルを直接編集する場合:
  -audi+ と記述します。

回答を閉じる

QC++プロジェクトのコンパイル依存性を軽減するメッセージは? QAC++2.5J

A
翻訳単位間の依存性を軽減すると、コンパイル速度が改善するほか、前方宣言による設計境界およびモジュール化の強制に役立つことがあります。QA C++ 2.5Jでは、ファイルのインクルードの削減を可能にする操作によってこれらの目的に対応するロジックが導入されました。診断に含まれるのは、同じヘッダ の反復的なインクルード、不要なヘッダのインクルード、および直接のインクルードを避けるためにクラスとテンプレートを前方宣言している可能性などです。
これらメッセージを以下に示します。
  • 1060: インクルードされたヘッダファイル'filename'は、直接このファイルによって使用されていません。
  • 1061: ヘッダファイル'filename'は既にこのファイルにインクルードされています。
  • 1062: クラス'name'はこのパスにおいて前方宣言されている可能性があります。
  • 1063: クラス'name'はこのパスにおいて使用されていません。
  • 1064: このパスでのクラス'name'の定義が遅い可能性があります。
  • 1065: このパスでのクラステンプレート'name'の定義が遅い可能性があります。

さらに、次の3つのサブメッセージがこれらメッセージと共に出力される場合があります。
  • 1490 (クラス'name'はこのヘッダでは使用されていません。)は、'name'がヘッダの中で全く参照されていない各ファイルで生成されます。
  • 1491 (ここではクラス'name'の宣言が使用されています。)は、'name'は「参照」されているが定義は必要とされない各ファイルで生成されます。(すなわち、'name'がポインタまたは参照として使用されている場合)
  • 1492 (ここではクラス'name'の定義が使用されています。)は、(ヘッダ・ファイルによる)型の定義が必要とされる場合に生成されます。

回答を閉じる

Qネットワークの問題の切り分け

A
問題

PERFORCEの応答時間の遅延はネットワークの問題によるものであると、どのようにして判定できますか



解決策

はじめに、PERFORCEのログファイルを調査し、標準のシステム管理ツールを使用して、応答時間の遅延を診断します。PERFORCEコマンドがロー カル・マシン上では迅速に実行され、ネットワーク経由では動作が遅い場合、ネットワークの問題であると思われます。または、PERFORCEログに情報が 提供されていれば、例えば経過時間と使用時間とを比較します。

非常に大きいユーザ処理によってPERFORCEサーバの応答が遅くなることも考えられますが、持続的にPERFORCEへの応答が遅い場合、通常はネッ トワークの問題が原因です。以下のいずれかの要因により、応答が遅くなることがあります。
  • ドメインネームサーバ(DNS) の構成の誤り
  • Windowsネームサーバ(WINS)またはWindowsドメインの構成の誤り
  • ネットワーク応答の遅延


  •    注意:

    ネットワークの問題の解決はこのノートの範囲外ですが、問題解決のための提案をいくつか示します。

    p4 info

    最初の試験として適切なのは、p4 info コマンドを実行することです。このコマンドがほぼ実行直後に応答しない場合、ネットワーク関連の問題があります。p4 info コマンドでは、PERFORCEサーバへの通信にP4PORTの設定が使用されます。P4PORT の設定にサーバマシンのホスト名が使用されていれば、サーバIPアドレスの取得にDNSルックアップが必要です。DNSサーバに障害があるかネットワーク が遅い場合は、ルックアップ処理に時間がかかります。直接IPアドレスを使用することで、DNSルックアップを回避することができます。

    ホスト名 対 IPアドレス

    クライアント・マシン上で、P4PORTの設定にPERFORCEサーバのIPアドレスを使用してみましょう。これにより、ホスト名のIPアドレスへの変換に使用されるDNSルックアップが回避されます。サーバのホスト名を使用したP4PORTの例を示します。
    P4PORT=hostname:1666

    IPアドレスを直接使用すると、P4PORTの設定は次のようになります。
    P4PORT=1.2.3.4:1666

    PERFORCEサーバマシンのIPアドレスが手元にない場合、ping コマンドを使用して知ることができます。pingコマンドの実行例は次のとおりです。
    ping hostname

    pingコマンドの出力には、ホスト名に対するIPアドレスが表示されます。

    P4PORTの設定にIPアドレスを使用したときに p4 info コマンドがすぐに応答する場合は、DNSの構成が誤っています。

    "p4 info" 対 P4Win

    p4 info コマンドはPERFORCEサーバによって処理されます。PERFORCEサーバがコマンドに対する出力情報を編集するとき、クライアントのIPアドレス に対してDNSリバースルックアップを行います。 DNSフォワードルックアップは高速である場合もありますが、DNSリバースルックアップは低速です。DNSリバースルックアップが低速であると判定する 1つの方法は、PERFORCE Windows クライアント P4Winを使用することです。P4Winでの「接続情報を表示」の操作では、DNSリバースルックアップを行いません。

    P4Winの「接続情報を表示」の応答と、コマンドラインでのp4 infoからの応答とを比較することができます。「接続情報を表示」の処理が速く、p4 infoが遅ければ、PERFORCEサーバマシンにはDNSリバースルックアップの問題があります。

       注意: この試験は、リリース 99.1 およびそれ以降のPERFORCEサーバに対してのみ有効です。99.1より前のリリースでは、PERFORCEサーバは要求がp4 infoから送られたかP4Winから送られたかにかかわらず、常に逆方向のネームルックアップを行っていました。 また、この試験では、P4V ではなく P4Win を用いなければならない点にもご注意ください。P4V の「接続情報を表示」は、逆方向のネームルックアップを行います。

    "hosts" ファイル

    ホスト名とIPアドレスのエントリをhostsファイルに追加することにより、DNSの問題を回避することができます。このタスクは通常、システム管理者によって実行されますが、各企業での標準の手続きに従ってください。

    P4PORTの設定にIPアドレスを使用する代わりに、ホスト名とIPアドレスのエントリをhostsファイルに追加することができます。hostsファ イルは見つけにくい場合があります。それを見つけるためのいくつかの場所を以下に示します。
  • NT/2000/XP: C:\Winnt\System32\Drivers\etc\hosts
  • Win98: C:\Windows\hosts and hosts.sam
  • Win95: C:\Windows\hosts and hosts.sam
  • Unix: /etc/hosts


  • Windows95および98では、hostsファイルをhosts.samファイルにコピーする必要があるかもしれません。

    hostsファイルのエントリの例を以下に示します。
    1.2.3.4 hostname

    DNSリバースルックアップに問題があると判定した場合は、クライアント・ホスト名のエントリをPERFORCEサーバマシンのhostsファイルに追加する必要があります。

    Windowsにおけるワイルドカード

    場合によっては、p4コマンドでディポ構文またはクライアント構文をワイルドカードと組み合わせた、引用符で囲んでいないファイルパターンを使用すると遅延が生じることがあります。
    p4 files //depot/*p4 files //client/*

    Windows用ワイルドカード拡張ルーチンがディポ名またはクライアント名をネットワーク・システム名と間違えることにより、遅延が発生します。ファイルパターンの前後に二重引用符を入れることにより、遅延を防ぐことができます。
    p4 files "//depot/*"

    ワイルドカードの特殊な取り扱いに関してさらに詳しくは、NOTE041「特殊文字の使用」を参照してください。

    ネットワークの形態

    今日のネットワークの多くは、100 Mbitテクノロジを使用しています。このタイプのネットワークにおける理論上の最大転送速度は、毎秒10メガバイトです。多くの場合、これより遅い転送 速度になることがあります。ネットワークが飽和状態になると、転送速度は毎秒4メガバイト程度まで大幅に低下します。このような場合、ネットワークルータ またはスイッチを使用すると役立つことがあります。

    ネットワーク・ファイルシステム上のクライアント

    p4コマンド(実行ファイル)自体が、パフォーマンスの非常に悪い、ネットワーク接続されたファイルシステム上にあることも考えられます。これをチェックするには、次のコマンドを実行してみましょう。
    p4 -V

    このコマンドは単にバージョン情報を出力するもので、ネットワークアクセスは一切試行しません。応答が遅ければ、p4コマンド自体へのネットワークアクセ スに問題がある可能性があります。p4コマンドの実行ファイルをローカル・ファイルシステムにコピーまたはダウンロードしてみてください。

    また、PERFORCEクライアント・ルートにネットワーク・ファイルシステムを使用すると、コマンドへの応答が遅くなることがあります。 PERFORCEクライアント・コマンドで転送されるすべてのバイトは、ネットワークを2度通過しなければなりません。うち1回はPERFORCEサーバ からPERFORCEクライアント・アプリケーションへの転送、もう1回はPERFORCEクライアント・アプリケーションからネットワーク・ファイルシ ステムへの転送です。ネットワークが飽和状態にあり、クライアント・ワークスペースに大きいファイルまたは多数のファイルがある場合、p4 sync などのコマンドが遅くなることが予想できます。PERFORCEクライアント・ワークスペースをローカル・ファイルシステムに移動させてみてください。

    ネットワーク・ファイルシステム上のサーバ

    PERFORCEサーバにネットワーク・ファイルシステムを使用することは非常に慎重に検討する必要があります。上記のPERFORCEクライアントのシ ナリオのように、サーバ・アプリケーションへのデータおよびサーバ・アプリケーションからのデータはネットワークを2度通過しなければなりません。また、 PERFORCEサーバは重大なデータファイルに対してファイルのロックを使用します。ネットワーク・ファイルシステムのすべてが効率的にロック機能を実 装しているわけではなく、一部にはバグが多いものもあります。

    ネットワークが飽和状態にあり、転送率が毎秒4メガバイト程度に低下している場合、PERFORCEサーバはクライアントの要求を満たすことはできませ ん。各クライアント要求はネットワークの一部を使用しており、PERFORCEサーバはネットワーク・ファイルシステムにアクセスするためにそのリソース を共有しなければなりません。昨今の安価なハードドライブでは、毎秒20メガバイト程度の転送率を提供します。良質なSCSIハードドライブでは毎秒 160メガバイト程度の転送が可能です。可能な限り、ネットワーク・ファイルシステムに関わるサーバのボトルネックを避けるようにしてください。

    NetAppファイラーなどの特殊用途向けネットワーク・ファイルシステムがある場合、プライベートなギガビットのファイバー接続を、直接 PERFORCEサーバマシンに対して使用することを検討してください。隔絶されたギガビット接続では、毎秒100メガバイトの転送率が得られることが見 込まれます。

    回答を閉じる

    QWindows環境変数の優先順位

    A
    概要

    PERFORCE環境変数の設定にはいくつかの手法があり、一部の設定が他の設定に優先されます。 この記事では、どのPERFORCE環境変数がWindows環境で優先されるのか、という基本的な質問にお答えします。

    この記事はWindows NT 4.0、Windows 2000、Windows XP、およびWindows 2003に適用されます。 Windows32ビット版およびWindows64ビット版の両方が対象となります。

    詳細

    PERFORCEクライアント(P4、P4VまたはP4Winなど)、PERFORCEプラグイン(P4SCCまたはP4 For Office)またはPERFORCEサーバのWindowsサービス(p4s.exe)が起動すると、それらは構成パラメータをPERFORCE Windows環境から読み込みます。 設定が見つかるまで、PERFORCE環境における優先順位が探索されます。 優先順位は以下のとおりです。
  • PERFORCEコマンドライン・オプション
  • PERFORCE P4CONFIGファイル(P4CONFIGが設定されている場合)
  • Windowsシステム環境変数およびユーザ環境変数
  • PERFORCEユーザ環境レジストリ(p4 set)
  • PERFORCEシステム環境レジストリ(p4 set -s)


  • リリース 99.1/10994以降、PERFORCE Windowsサービスが起動すると、別の場所から構成を読み込みます。 p4s.exe、p4ps.exe、p4webs.exe、およびp4ftps.exeを含むすべてのPERFORCEサービスにおいて、この別の場所が使用されています。 PERFORCE Windowsサービスの優先順位は以下のとおりです。
  • PERFORCE Windowsサービス・パラメータ (p4 set -S サービス名)
  • Windowsシステム環境変数
  • PERFORCEシステム環境レジストリ


  • Windows 64ビット環境でのレジストリ リフレクション

    32ビットのアプリケーションがWindows 64ビットOSで実行されると、レジストリアクセスが反映されます。 この領域でのレジストリの読み取りまたは書き込みは、下に示す2番目のレジストリ領域に反映されます。 (これはMicrosoftによる動作の描写です。現実には、むしろレジストリ リダイレクションであり、両方ではなく一方または他方の領域がアクセスされます。)
    HKEY_LOCAL_MACHINE/Software -->> HKEY_LOCAL_MACHINE/Software/Wow6432Node

    このレジストリ リダイレクションのために、2005.2のPERFORCE Windows 64ビットのサーバ(NTX64)は、他の2005.2 PERFORCE Windows 32ビット(NTX86)のクライアントおよびサーバとは互換性がありません。 PERFORCEでは、Microsoftのレジストリ リフレクションの結果を永続的にするパッチを適用することを選択しました。 PERFORCE Windows 64ビットサーバであるNTX64では、それが32ビットのアプリケーションであるかのように反映されたレジストリ領域を使用するようになりました。 この解決策を採用したのは、すべてのPERFORCEクライアントは当分の間32ビットのアプリケーションとして残存するからです。

    すべての2006.n のPERFORCEサーバ・バージョン、および"NTX86/2005.2/94595"より後の2005.2のPERFORCEサーバ・バージョンではこの動作に従います。 P4コマンドライン・クライアントおよびその他のPERFORCEクライアントでは、必要に応じて自動的に環境設定を反映されたレジストリ領域に書き込むため、ユーザが特にアクションを取る必要はありません。

    回答を閉じる

    Q大文字/小文字の問題とマルチ・プラットフォームの開発

    A
    背景

    p4 addを 用いてPERFORCEのディポにファイルが追加されると、サーバルート配下にアーカイブ・ファイル(例えば、$P4ROOT/depot/main /file1,v)が書き込まれます。併せて、関連するメタデータのエントリがPERFORCEのデータベース・ファイル(例えば、$P4ROOT /db.rev)に書き込まれます。新しいアーカイブ・ファイル(およびメタデータ・エントリ)は、 p4 integrate を用いた場合にも書き込まれます。大文字/小文字を区別するプラットフォーム上でPERFORCEを使用しているとき、 このメタデータとアーカイブ・ファイルとの間で、大文字/小文字が異なってしまう可能性があります。


    大文字/小文字を区別する必要がある動作

    UNIX上のPERFORCEサーバは、名前における大文字/小文字の違いをサポートします。Windows上のPERFORCE サーバは、大文字/小文字の違いを無視します。ジョブにおけるキーワードの検索では、常に大文字/小文字は無視されます。これをまとめると、下表のように なります。
    大文字/小文字の区別 UNIXサーバ Windowsサーバ
    パス名およびファイル名 区別する 区別しない
    データベース・エントリ
    (クライアント名、ラベル名、等)
    区別する 区別しない
    ジョブ検索のキーワード 区別しない 区別しない



    現在のPERFORCEサーバがどのプラットフォーム上で実行しているかを調べるには、 p4 infoを実行します。

    以下のセクションでは、PERFORCEサーバとPERFORCEクライアントの様々な組み合わせにおいて、大文字/小文字をハンドリングする動作について説明しています。

    UNIXサーバ + UNIXクライアント
    問題なし --- メタデータとアーカイブ・ファイルの大文字/小文字は常に一致します。

    Windowsサーバ + Windowsクライアント
    問題なし --- メタデータとアーカイブ・ファイルとの間に大文字/小文字の違いが発生する可能性があります。しかし、これらの違いは無視されます。

    UNIXサーバ + Windowsクライアント
    潜在的な問題 -- UNIX(およびUNIXファイルシステム)上のPERFORCEサーバは、大文字/小文字が混在したファイルを保持する可能性があります。 一方、Windowsファイルシステムは大文字/小文字が混在したファイルを保持することができません。

    Windowsサーバ + UNIXクライアント
    潜 在的な問題 --- Windows上のPERFORCEサーバは、大文字/小文字が混在したメタデータを管理することができます。結果として、 WindowsベースのPERFORCEサーバにおいて1つのディレクトリに存在するファイルが、UNIXベースのPERFORCEクライアント・ワーク スペース内では2つ以上の大文字/小文字が異なった別ディレクトリに存在しているのかもしれません。

    UNIXサーバ + Windowsクライアント(詳細)

    PERFORCEサーバがUNIX上にあり、かつUNIXからアクセスするユーザとWindowsからアクセスするユーザの両方が存在する場合、UNIX ユーザは、ファイル名の大文字/小文字のみが異なるファイルをサブミットしないよう注意が必要です。UNIXサーバ自体はこういったファイルをサポートし ますが、Windowsユーザがこのようなファイルをクライアント・ワークスペース同期すると、大文字/小文字だけが異なるディレクトリやファイルは、お 互いに上書きし合うことになります。

    例えば、UNIXベースのPERFORCEサーバ上において、あるファイルが大文字/小文字の異なる2つのディレクトリ配下に存在し、それらを "main/file1" および "MAIN/file1" とします。次のコマンドを UNIXベースのPERFORCEクライアントから実行したときは、期待どおり、2つの大文字/小文字が異なるディレクトリ配下に2つの異なるファイルと して同期されます。:
    p4 sync main/file1
    p4 sync MAIN/file1

    しかしながら、同じコマンドをWindows上のPERFORCEクライアントから実行すると、2つの異なるファイルはクライアント・ワークスペース内の同一ディレクトリに同期され、最後の同期操作がそれ以前に同期したファイルを上書きしてしまいます。


    ファイルの保存方式に加え、大文字/小文字はPERFORCEクライアントのエンティティにも影響を与えます。 UNIX上のPERFORCEサーバは、ユーザ名、クライアント名、ブランチ仕様名、ラベル名に対して 大文字/小文字を意識します。UNIXサーバに接続しているWindowsユーザは、新しいクライアント・ワークスペースに対するデフォルトの名前とし て、小文字のホスト名が使われることに気を付ける必要があります。例えば、ホスト名 "ROCKET" のマシン上で新しいユーザがクライアント仕様を作ると、そのクライアント・ワークスペース名はデフォルトで "rocket" となります。もし、そのユーザが後でP4CLIENTを "ROCKET" または "Rocket" に設定してしまうと、PERFORCEは「そのクライアント・ワークスペースは未定義」と認識します。このクライアント・ワークスペースを使用するには、 P4CLIENTを "rocket" に設定する(もしくはP4CLIENTを設定しない)必要があります。


    Windowsサーバ + UNIXクライアント(詳細)

    PERFORCEサーバがWindows上で動作している場合、UNIXクライアントからアクセスしているユーザは、大文字/小文字の異なるファイルが同 一の名前空間に保存されることを意識しなければなりません。例えば、次のコマンドをUNIXのクライアント・ワークスペースから実行すると、両方のファイ ルはWindowsサーバ上で同じディポ・ディレクトリに格納されます。:
    p4 add dev/file1
    p4 add DEV/file2

    サーバ上のディポ・ファイルにおいて、Windowsサーバがディポ・パスとファイル名を割り当てる際、最初に見つかった名前が採用されます。上記の例で は、ファイルシステム上に保存されるディポ・パス名は "dev" となります。しかしながら、PERFORCEのメタデータにおけるパスおよびファイル名の大文字/小文字は、ユーザから入力されたままの状態で維持されま す。PERFORCEサーバは、これに基づいてファイルの場所を追跡しますので、大文字/小文字の違いを認識するUNIX上のクライアント・ワークスペー ス内では、これらのファイルは異なるファイルとしてアクセスされます。

    Windowsユーザは、新しいファイルを追加する際に、ファイル名やパス名の大文字/小文字に関して一貫性を保つように注意しなければなりません。Windowsクライアントから//depot/main/foo.cおよび //depot/MAIN/bar.cと して追加されたファイルは、UNIXユーザのクライアント・ワークスペースにおいては、2つの異なるディレクトリ配下のファイルとして同期されてしまいま す。Windowsサーバにおけるファイルは、ディポ・ファイルでは大文字のみ(または小文字のみ)のファイルとして格納されたとしても、メタデータでは 追加されたときの大文字/小文字が保持されます。また、ディレクトリ・パスにおける実際の大文字/小文字は、コマンドラインでどのように入力されたか、ま たはドラッグ&ドロップ操作においてOSがどのように取り扱ったかによって、変化する可能性があります。

    パス名の大文字/小文字に確実に一貫性を持たせる方法として、サブミット前のトリガがあります。このトリガのサンプルは、Perforce Software社のパブリック・ディポにおいて参照することができます。: http://public.perforce.com/public/perforce/utils/index.html#triggers



    大文字/小文字の問題を検出し解決する

    大文字/小文字の問題を検出する方法として、p4 verifyを定期的に実行する方法があります。例えば、次のように実行します。:
    p4 verify -q //...

    p4 verifyは、関連するディポ・ファイルに対して、各リビジョンのメタデータ・エントリをチェックします。UNIXサーバにおいて、ディポ・ファイルの大文字/小文字がメタデータ・エントリと異なることを検出すると、 ディポにない!MISSING!)と出力されます。使用方法の詳細につきましては、PERFORCE コマンド・リファレンスをご参照ください。

    もし、ファイル名の大文字/小文字に関して問題をお持ちの方は、どうぞご遠慮なく 弊社テクニカルサポートにお問い合わせください。


    経緯

    PERFORCEの以前のリリース(97.2より前)においては、すべてのファイル名、パス名およびデータベース・エントリに対して、サーバがUNIX上で動作していようがWindows上で動作していようが、大文字/小文字の区別を行っていました。例えば、//depot/main/foo.cおよび//depot/MAIN/bar.cは、 まったく異なる 2つのファイルとして取り扱っていました。ところが、Windows上のPERFORCEサーバに接続しているUNIX上のユーザがいるサイトでは、この 仕様によって問題が発生します。つまり、サーバ上のファイルシステムでは大文字/小文字の意識がないため、UNIXユーザによってサブミットされたファイ ルの大文字/小文字を区別できないということです。(もし、Windows上で97.2より前のサーバを動作させている方は、サーバ・プログラムとデータ ベースのアップグレードをお勧め致します。弊社テクニカルサポートへご連絡ください。)

    リリース97.3において、UNIXサーバのみが名前の大文字/小文字を区別するようになりました。しかしながら、 UNIX/Windowsの混在環境で開発を行う場合、まだ大文字/小文字に関するいくつかの問題があります。

    リリース2000.1において、Windows上のPERFORCEサーバでは、すべてのディポ・ファイルが小文字で格納されるようになりました。この変 更は、もしこの環境をUNIX上へ移行することを考えたとき、その移行をし易くします。つまり、WindowsからUNIXへの移行においては、大文字/ 小文字に関して何も意識する必要はありません。代わりに、異なるプラットフォーム間でPERFORCEサーバを移動したときには、p4 verifyの実行が必須となり、これによって大文字/小文字に関する問題を検出することができます。PERFORCEサーバの移動に関しては、テクニカルノート NOTE010をご参照ください。

     

    回答を閉じる

    Q2つのラベルを同期させる

    A
    解決策

    PERFORCEでは、ラベルはファイル名とリビジョンのリストです。 p4 sync @labelname の意味は、他のSCMシステムにおける「ラベルに基づいたチェックアウト」の意味とは異なります。 コマンドでファイル・パターンが指定されている場合を除き、p4 syncはワークスペース・ビュー全体を処理するため、p4 sync @labelname はラベルにリストされていないファイルを削除することも含め、ワークスペース全体をラベルと同期させます。

    したがって、2つのラベルがある場合、連続して各ラベルにクライアント・ワークスペース全体を同期させても、2つのラベルが融合されるわけではありません。 単に、2番目のラベルに同期された状態になるだけです。 しかし、p4 sync コマンドでファイル・パターンを指定することにより、影響を受けるファイルを制限することができます。 例えば、
    p4 sync //depot/projectA/...@label とすると、//depot/projectA にあるファイルにのみ影響します。

    ワークスペースからファイルを一切削除することなく、あるラベルが付けられたファイルと同期させたい場合は、@label,label の構文を使用します。 例えば、
    p4 sync @label,label とすると、label により指定されたファイルだけを同期し、他のクライアント・ファイルは処理しません。

    繰り返しますが、p4 sync に @label 構文(@label,labelではなく)を使用して実行すると、ワークスペース内のファイルでラベルにリストされていないものは削除されます。

    この動作は一貫していますが、他のSCMシステムを使い慣れているユーザには混乱を招くかもしれません。 このような疑問を起こさせる、典型的なシナリオを以下に示します。

    プロジェクトAに従事しているユーザが自分たちのファイルにラベル(A42とする)を付けた
    プロジェクトBに従事しているユーザが自分たちのファイルにラベル(B42とする)を付けた
    「ビルド・プロセス」ではA42およびB42により指定されているファイルが必要である

    プロジェクトAとプロジェクトBがディポ内の別々のディレクトリを占有している場合、次のコマンドで両方のラベルを一度に取得できます。
    p4 sync //depot/projectA/...@A42 //depot/projectB/...@B42 しかし、プロジェクトAとプロジェクトBのディレクトリ編成によってこれが可能でない場合、ラベルA42とラベルB42とが融合されたラベルを作成することができます。
    p4 labelsync -l both42 @A42p4 labelsync -a -l both42 @B42 (-a(追加)オプションはリリース97.3でp4 labelに追加されています)

    こうして、次のコマンドで両方のプロジェクトのラベル付けされたファイルと同期させることができます。
    p4 sync @both42 融合されたラベルを作成するのとは別に、上述した @label,label 構文を使用する方法があります。 このシナリオでは、(任意で)ワークスペースを空にして、順番に各ラベルと同期させることができます。 例を示します。
    p4 sync #nonep4 sync @A42,A42p4 sync @B42,B42 ラベルやその他のリビジョン指定子にファイルを同期させるどの場合でも、編集目的で作業状態にされたファイルは処理されないことを覚えておいてください。

    ラベルとPERFORCEについての議論は、アトミックな変更との関係に言及しなければ不完全といえるでしょう。 ほとんどのSCMシステムでは、アトミックな変更がサポートされていないためにラベルが使用されており、リビジョンにラベルを付けることが、特定のコード断面のスナップショットを表す唯一の方法です。 例えばほとんどのファイルが火曜日のものであるが特定のファイルは金曜日のものであるなど、整合しない断面を表している場合を除いて、PERFORCEでは、ラベルを使用する必要は全くありません。 上記で "@labelname" を用いて指定されたすべてのラベルは、チェンジ番号に置き換えることができます。

    回答を閉じる

    QPERFORCEサーバのアップグレード

    A
    解決策

    新しいバージョンの PERFORCEサーバを実行するには、お使いの PERFORCE ライ センスが最新でなければなりません。期限が切れたライセンスは、アップグレー ドしたサーバでは機能しません。ライセンス無しの環境で起動している場合に は、問題になりません。ライセンス無しの PERFORCEサーバ環境では、2人のユー ザと 2つ(2004.2 以前)または 5つ(2005.1 以降)の ワークスペースに制限 されます。ライセンス無し環境は、PERFORCE の評価目的で使用されることがあ ります。

    アップグレード作業を進める前に、現行バージョンの PERFORCEサーバに施され た最新の変更を確実に把握するため、PERFORCE リリース ノート をご参照ください。

    基本的に、PERFORCEサーバをダウングレードすることはできません。したがっ て、PERFORCEサーバをアップグレードする前に必ずチェックポイントを作成す る必要があります。

    基本的に、どのバージョンの PERFORCEサーバからであっても、アップグレード を実行することが可能です。例えば 2007.2 から 2009.2 へ、直接アップグレー ドすることができます。段階的に、個々のバージョンへアップグレードする必 要はありません。ビルトインのアップグレード処理は、自動的に PERFORCE デー タベースの更新を段階的に行い、その結果を出力します。

    十分なライセンスを取得している(またはライセンス無しで 2ユーザ/2つまた は 5つのワークスペースを持つ環境で運用している)と想定すると、最近のリ リースからアップグレードする場合には、PERFORCEサーバのアップグレードは 単に以下の手順を実行するだけで済みます。
    1.  現在稼動中の p4d を停止します。
    2.  次のコマンドを実行して、データベースのチェックポイントを作成します。 ただし、"root" は db.* ファイルが格納されているディレクトリを指します。 p4d -r root -jc
    3.  バージョン化ファイルをバックアップします。
    4.  新しい p4d 実行可能モジュールをダウンロードします。Windows の場合は、 インストーラ perforce_ja.exe または perforce64_ja.exe をダウンロードします。
    5.  新しい p4d を適切な場所にインストールします。Windows の場合は、 インストーラ perforce_ja.exe または perforce64_ja.exe を実行します。
    6.  以下のコマンドを実行します。 p4d -xu -r root
    7.  通常お使いのパラメータで p4d を再起動します。

    アップグレードが完了した後に、考慮すべきオプション作業があります。それは、将来的に db.* ファイルを復旧する場合に備えて、新しく更新したデータベースのチェックポイントを作成することです。新しいチェックポイントを作 成するには、上記の 1. および 2. の手順を再実行します。

    データベースのチェックポイント作成およびバージョン化ファイルのバックアップに関する情報は、『PERFORCE システム管理者ガイド』の「PERFORCE のサポート:バックアップとリカバリ」をご参照ください。

    2001.1 より前のリリースから PERFORCEサーバをアップグレードする場合は、その他にも考慮事項があるかもしれません。2001.1 より前のリリースからのアップグレードを確実に成功させるためには、弊社テクニカルサポートにお問い合わせください。

    日本語版 PERFORCE をアップグレードする場合は、必ず PERFORCE 技術情報の「ご注意!」 をご参照ください。

    リリース 2005.1 以降へアップグレードする場合、それ以前にディポへ登録されたすべてのファイルを対象に、ファイル名の長さをメタデータとして記録するため、当該アップグ レードに続いて少なくとも 1回、"p4 verify -u" を実行しなければなりません。詳しくは、Important Notes for 2005.1 and later. をご参照いただくか、弊社テクニカルサポートにお問い合わせください。

    古い PERFORCE クライアント・プログラム(p4、P4Win、P4V および P4SCC)は、より新しいサーバ・バージョンと共に問題なく動作します。新しいサーバ・リリースのいくつかの機能を動作させるには、クライアントのアッ プグレードも必要になります。より古いクライアント・プログラムを稼動させているユーザは新しいサーバ機能を使用できません。

    PERFORCE のリモート・ディポのサポートは、すべての PERFORCEサーバがリリース 98.2 以降であることを必要とします。2005.1 以降のサーバは、99.2 以降のサーバからのみリモート・ディポとして使用できます。

    メタデータのデータベース・スキーマのアップグレード

    相当な量のメタデータ・データベース・スキーマをアップグレードするには、'p4d -xu' コマンドを実行します。一般的に 'p4d -xu' コマンドは、1,000個以上のチェンジリストを持つサーバをアップグレードする際に必要となります。サーバの持つチェンジリストが 1,000個より少ない場合には、新しいサーバの起動時に、自動的にアップグレードされます。1,000個以上のチェンジリストを含むメタデータ・データ ベースを使用し、相当量のスキーマのアップグレードが必要である新しいサーバを起動しようとすると、次のサーバ・エラーが発生します。
    Database is at old upgrade level x. Use 'p4d -xu' to upgrade to level y

    ただし、x および y はサーバ内部のアップグレード・レベルを示します。

    エラーの出力後に、サーバは強制終了されます。Windows 環境では、エラー・メッセージはサーバ・ログに書き出されますが、表示されません。

    場合によっては、サーバ・アップグレードにおいて 'p4d -xu' コマンドを必要としません。例えば、2005.2 のサーバを 2006.1 にアップグレードする場合は、チェンジリストの数にかかわらず、'p4d -xu'を実行する必要はありません。しかし、以前に 2006.1サーバによって使用されていたメタデータ・データベースを使用し、2005.2サーバを単に起動したとしても、2006.1サーバを 2005.2 にダウングレードできるわけではありません。新しいサーバでは、そのサーバが実行される際に、メタデータ・データベースのスキーマの変更がさらに行われま す。

    必要とされる追加の空き領域

    ほとんどのアップグレードにおいて、db.* ファイルおよびジャーナル用に、追加の空き領域が必要です。p4d -xu コマンド実行の際、それぞれに対して必要とされる最大追加空き領域を、以下の表に示します。表に示した内容は最悪な場合のシナリオに基づいているため、ほ とんどのアップグレードでは、実際に使用される追加空き領域は表に示したサイズよりも少なくなります。

    2008.2 または 2009.2 の p4d -xu 実行中に必要な最大追加空き領域
    アップグレード
    前のリリース
    db.* ファイルに必要な
    最大追加空き領域
    ジャーナルに必要な
    最大追加空き領域
    2008.1 なし 以前のバージョンからのアップグレード要求
    に対する 2008.1 -xu をご参照ください。
    2007.3 db.revのサイズの0.5倍 db.changeのサイズ
    + db.revのサイズの0.5倍
    2007.2 db.revのサイズの1.5倍
    + db.viewのサイズ
    db.changeのサイズ
    + db.revのサイズの1.5倍
    + db.viewのサイズ
    2006.2 db.revのサイズの1.5倍
    + db.viewのサイズ
    db.changeのサイズ
    + db.revのサイズの1.5倍
    + db.viewのサイズ
    2006.1 db.revのサイズの1.5倍
    + db.viewのサイズ
    db.changeのサイズ
    + db.revのサイズの1.5倍
    + db.viewのサイズ
    2005.2 db.revのサイズの1.5倍
    + db.viewのサイズ
    db.changeのサイズ
    + db.revのサイズの1.5倍
    + db.viewのサイズ
    2005.1 db.revのサイズの3.5倍
    + db.viewのサイズ
    db.changeのサイズ
    + db.revのサイズの4.5倍
    + db.viewのサイズ
    2004.2 db.revのサイズの3.5倍
    + db.viewのサイズ
    db.changeのサイズ
    + db.revのサイズの6.5倍
    + db.viewのサイズ

    2007.3 の p4d -xu 実行中に必要な最大追加空き領域
    アップグレード
    前のリリース
    db.* ファイルに必要な
    最大追加空き領域
    ジャーナルに必要な
    最大追加空き領域
    2007.2 db.revのサイズ
    + db.viewのサイズ
    db.revのサイズ
    + db.viewのサイズ
    2006.2 db.revのサイズ
    + db.viewのサイズ
    db.revのサイズ
    + db.viewのサイズ
    2006.1 db.revのサイズ
    + db.viewのサイズ
    db.revのサイズ
    + db.viewのサイズ
    2005.2 db.revのサイズ
    + db.viewのサイズ
    db.revのサイズ
    + db.viewのサイズ
    2005.1 db.revのサイズの3倍
    + db.viewのサイズ
    db.revのサイズの4倍
    + db.viewのサイズ
    2004.2 db.revのサイズの5倍
    + db.viewのサイズ
    db.revのサイズの6倍
    + db.viewのサイズ

    2007.2 の p4d -xu 実行中に必要な最大追加空き領域
    アップグレード
    前のリリース
    db.* ファイルに必要な
    最大追加空き領域
    ジャーナルに必要な
    最大追加空き領域
    2006.2 0 0
    2006.1 db.revのサイズ db.revのサイズ
    2005.2 db.revのサイズ db.revのサイズ
    2005.1 db.revのサイズの3倍
    + db.viewのサイズ
    db.revのサイズの4倍
    + db.viewのサイズ
    2004.2 db.revのサイズの5倍
    + db.viewのサイズ
    db.revのサイズの6倍
    + db.viewのサイズ

    2006.2 の p4d -xu 実行中に必要な最大追加空き領域
    アップグレード
    前のリリース
    db.* ファイルに必要な
    最大追加空き領域
    ジャーナルに必要な
    最大追加空き領域
    2006.1 db.revのサイズ db.revのサイズ
    2005.2 db.revのサイズ db.revのサイズ
    2005.1 db.revのサイズの3倍
    + db.viewのサイズ
    db.revのサイズの4倍
    + db.viewのサイズ
    2004.2 db.revのサイズの5倍
    + db.viewのサイズ
    db.revのサイズの6倍
    + db.viewのサイズ

    2006.1 の p4d -xu 実行中に必要な最大追加空き領域
    アップグレード
    前のリリース
    db.* ファイルに必要な
    最大追加空き領域
    ジャーナルに必要な
    最大追加空き領域
    2005.2 db.revのサイズ db.revのサイズ
    2005.1 db.revのサイズの2倍
    + db.viewのサイズ
    db.revのサイズの3倍
    + db.viewのサイズ
    2004.2 db.revのサイズの4倍
    + db.viewのサイズ
    db.revのサイズの5倍
    + db.viewのサイズ

    2005.2 の p4d -xu 実行中に必要な最大追加空き領域
    アップグレード
    前のリリース
    db.* ファイルに必要な
    最大追加空き領域
    ジャーナルに必要な
    最大追加空き領域
    2005.1 db.revのサイズの2倍
    + db.viewのサイズ
    db.revのサイズの3倍
    + db.viewのサイズ
    2004.2 db.revのサイズの4倍
    + db.viewのサイズ
    db.revのサイズの5倍
    + db.viewのサイズ

    2005.1 の p4d -xu 実行中に必要な最大追加空き領域
    アップグレード
    前のリリース
    db.* ファイルに必要な
    最大追加空き領域
    ジャーナルに必要な
    最大追加空き領域
    2004.2 db.revのサイズの2倍
    + db.viewのサイズ
    db.revのサイズの2倍
    + db.viewのサイズ

    2002.1 より前のリリースから PERFORCEサーバをアップグレードする際、ジョブを使用する場合は、p4 jobs -R を実行してジョブの索引を再作成しなければなりません。p4 jobs -R の実行中に db.* ファイルに対して必要とされる最大追加空き領域は、db.ixtext のサイズと同じです。p4 jobs -R の実行中にジャーナルに対して必要とされる最大追加空き領域は、db.ixtext のサイズの 3倍、db.boddate のサイズの 2倍、db.bodtext のサイズの 2倍、および db.ixdateのサイズの 2倍を合計した大きさになります。

    ジャーナルに必要とされる追加空き領域を最小にするには、アップグレード実行中はジャーナルの記録を無効にします。アップグレードが正常に終了したら、ただちにジャーナルの記録を有効にし、チェックポイント作成を行ってくださ い。ジャーナル記録の有効化および無効化に関しては、『PERFORCE システム管理者ガイド』の「PERFORCE のサポート:バックアップとリカバリ」にある「ジャーナル・ファイル」のセクションをご参照ください。

    回答を閉じる

    QSTUNVにカウントされる変数のうち、「再利用されていない変数」の意味を教えてください

    A

    関数のパラメータとして設定(set)されたが関数内部で使用されていないという意味です。
    Version: 4.2J
    OS: SunOS 4.x, SunOS 5.x, HP-UX 9.x, HP-UX 10.x, Windows 95/98/NT 4.0

    コマンドラインマニュアル(p77)のSTUNVの説明に「未使用および再使用されていない変数の数」とあるのは、

    未使用:回答1の(例)16,17行目のように宣言されたが使用されていない
    再使用:回答1の(例)の13行目のように関数のパラメータとして設定(set)されたが関数内部で使用されていない

    という意味です。

    STUNVの定義が英語のコマンドラインマニュアルで、"The number of unused and non-reused variables" となっている以上「未使用および再使用されていない変数の数」という日本語になってしまうことをご了承いただけないでしょうか。

    回答を閉じる

    QSTUNVで指摘された変数名を表示する方法はありますか?

    A

    3205と3206番のメッセージの数をカウントします。
    Version: 4.2J
    OS: SunOS 4.x, SunOS 5.x, HP-UX 9.x, HP-UX 10.x, Windows 95/98/NT 4.0

    STUNV(関数単位で測定するメトリック)でカウントされるのは、カテゴリ2の「メンテナンスの問題」に含まれる3205と3206番のメッセージの個数です。

    3205 変数 '%s'はその有効範囲(scope)で使用されていません。削除可能です。
    3206 引数 '%s'はこの関数では使用されていません。

    これらは注釈つきソースコード(list.qac)で表示されます。こちらをご覧いただきますと、変数名がわかります。

    また、static変数については、関数単位で測定するメトリックではありませんので、使用されていない場合でも STUNVにはカウントされません。未使用の場合、3207番のメッセージでのみわかります。(例10行目を参照ください)

    3207 'static'と宣言された変数'%s'は使用されていません。削除可能です。

    static変数に関するメトリックは(ファイル単位で測定するメトリックのうちの) 宣言されている静的変数の総数 (STSCT)です。

    (例)
    6: #include
    7:
    8: #include "test.h"
    9:
    10: static int AAA;
              ^
    C:\src\test.c(11) ++ WARNING ++: <=2=(3207) 'static'と宣言された変数'AAA'は使用されていません。削除可能です。
    11:
    12:
    13: int sub_asm1(short param1, short param2)
                             ^
    C:\src\test.c(13) ++ WARNING ++: <=2=(3206) 引数 'param2' はこの関数では使用されていません。
    14: {
    15:  int iParam;
    16:  int k;
           ^
    C:\src\test.c(16) ++ WARNING ++: <=2=(3205) 変数 'k'はその有効範囲(scope)で使用されていません。削除可能です。
    17:  int j;
           ^
    C:\src\test.c(17) ++ WARNING ++: <=2=(3205) 変数 'j'はその有効範囲(scope)で使用されていません。削除可能です。

    ...

    36: return iParam;
    37: }

    回答を閉じる

    QSTNTB, STTKB, STBCS, STCOMの数値が出力されません?

    A

    4つのメトリックはデリミタに相当する識別子で、それ自体に値はありません。 Version: 4.2J
    OS: SunOS 4.x, SunOS 5.x, HP-UX 9.x, HP-UX 10.x, Windows 95/98/NT 4.0

    Analyze.metを例に示します。4つのメトリックはデリミタに相当する識別子で、それ自体に値はありません。

    その意味を以下に示します。

    STNTB:ここからは、非トークンベースのメトリックスです
    STTKB:ここからは、トークンベースのメトリックスです
    STBCS:ここからは、COCOMO統計を元にしたメトリックスです
    STCOM:ここからは、コメントベースのメトリックスです

    Analyze.met
    <S>
    <S>STFIL C:\QACJ\demo\Analyze.c
    <S>STNAM C:\QACJ\demo\Analyze.c
    <S>STNTB NON-TOKEN BASED STATISTICS...
    <S>STSCT 10
    <S>STECT 48
    <S>STFNC 8
    <S>STFCO 52
    <S>STTKB TOKEN BASED STATISTICS...
    <S>STVAR 452
    <S>STOPT 66 (t1)
    <S>STOPN 857 (t2)
    <S>STTOT 7767 (n)
    <S>STZIP 6835
    <S>STHAL 8749
    <S>STSHN 35662
    <S>STDIF 19.09
    <S>STEFF 1460659
    <S>STVOL 76506
    <S>STDEV 243.44
    <S>STPRT 9.24
    <S>STMOB 96.20
    <S>STBUG 13
    <S>STTPP 924
    <S>STTLN 774
    <S>STBCS BASIC COCOMO STATISTICS...
    <S>STBMO 2.209
    <S>STBMS 2.746
    <S>STBME 3.274
    <S>STTDO 3.378
    <S>STTDS 3.560
    <S>STTDE 3.654
    <S>STCOM COMMENT BASED STATISTICS...
    <S>STCDN 0.768

    回答を閉じる

    Qプログラム難易度(STDIF)が小、流用度(STMOB)が良、プログラム規模(STVOL)が小なのに、バグ見積(STBUG)が非常に大きい理由はなんですか?

    A

    STBUGは、オペランド数(STOPN)または変数の数(STVAR)が大きいと、大きな値になります。
    Version: 4.2J
    OS: SunOS 4.x, SunOS 5.x, HP-UX 9.x, HP-UX 10.x, Windows 95/98/NT 4.0

    拝見したファイルの中の STBUGを見る限りは、1ファイル当り特別に大きな STBUGが出ている例は見当たりません。せいぜい多くても1か2程度のようです。

    STBUGの定義を今一度コマンドライン・マニュアルでご確認いただきたいのですが、STBUGは、オペランド数(STOPN)または変数の数 (STVAR)が大きいと、非常に大きな値となってきます。外部変数の数(STECT)が桁違いに大きい場合、それが足を引っ張ります。

    各ファイルについて、STOPN, STVAR, STECTの各値をチェックしてみて下さい。バグ見積(STBUG)が大きいファイルは、外部関数の定義部が非常に大きな場所を占めている形になっていると思います。

    QA Cの STBUGは、その算出基準から見て、多くの種類の定義が入ったファイルに対しては大きな値を示すようにできています。しかしながら、これが直ちに、外部 変数を使うのは好ましくない、という風に短絡することはできないことは、ソフトウェアを作成される方ならおわかりいただけるところで、論理を記述する上で 必要であれば、それを削ってまで QA Cの成績を上げることのみを優先する必要はありません。ただ、一般論として、あまりにも多くの外部変数を必要とする場合には、やはり保守性の面で難がある ことは否定できませんが‥‥

    強調しておきたいのは、STBUGが「バグ見積」と名前が付いているからと言っても、これが「バグが必ずxx個あります」という指標ではない、ということです。

    各メトリックスは、複雑なソフトウェアの「品質」を極力単純な数式で代表させることはできないか、という観点で各研究者が知恵を絞ってきた事柄で す。よって、アンプの世界と同様に、自ずから有効な帯域というものがあります。全体の8割位の解析対象に対して、実感と近い値が出ていれば、それで十分と 考えて下さい。

    例えば、イベント駆動型のプログラムでは、少なくとも1箇所は大規模な switch-caseによるイベント分岐が存在し、非常に大きな経路複雑度(STCYC)を持ちます。

    しかし、この関数を STCYCを下げるためだけに、switch-caseを分割するとしたら、それは無茶というものではないでしょうか。また、経路複雑度(STPTH)に ついては、たった1つの関数の STPTHが 50,000,000を示しただけで、他の関数の STPTHが良好であっても、平均値を求めると、とてつもなく大きな値になってしまいます。

    よって、各メトリックスの算出基準を理解し、どのファクターが大きい(小さい)と極端な値を示すか知った上で、該当するファイル(関数)において、 そのファクターが大きい(小さい)ならば見逃す、というような運用を貴社で徐々に積み上げていただければ、と思います。今後、QA Cのメトリックスを活用していただくに際して、現実の数値と QA Cの 出力値とを、絶えずペアで蓄積していただくことをお勧め致します。

    貴社におかれましても、独自の算出方法で各種の実測値を算出されていらっしゃる ことと思います。すぐには相関関係は見出せないとは思いますが、一方に実測値、 他方に QA Cの出力をプロットした場合、 (縦横はどちらでも構いませんが)相互に 1次関数で近似できたり、対数を取ると比例関係が見出せることがあります。 そこまでデータが蓄積できたら、近似式 Y=aX+b の係数 a, bを求めてみて 下さい。QA Cの出力値を、貴社の実測値の尺度に合わせることができます。

    回答を閉じる

    QSTLIN(保守可能なコード行数)は、関数の総ステップのことですか?

    A

    関数の総ステップを数えます。
    Version: 4.2J
    OS: SunOS 4.x, SunOS 5.x, HP-UX 9.x, HP-UX 10.x, Windows 95/98/NT 4.0

    QACでは、ステップ数(=行数)を示すメトリックスとして、以下の4種類を備えています。
    ([関]=関数メトリックス、[フ]=ファイルメトリックス)

    (1)[フ]STTPP:プリプロセス前の行数
        ファイル内の全ての行数を数えたものです。

    (2)[フ]STTLN:プリプロセス後の行数
        プリプロセスを経て、マクロ定義等を展開した後の総行数です。

    (3)[関]STLIN:保守可能なコード行数
        関数内('{'と'}'の間)に書かれている全ての行数を数えたものです。

    (4)[関]STXLN:実行コード行数
        関数内の全ての実行行を数えたもので、以下のものは数えません。
        ・コメントのみの行、空行、'{'または'}'のみの行、宣言行

    よって、ご指摘通り「関数の総ステップ(コメント行も含む)」を数えます。

    回答を閉じる

    QSTVOL(プログラム規模)について、バイト換算で示したいときは、 STVOLの値を 8で割ればよいですか?

    A

    STVOLはバイト換算も、8で割る必要もないと思われます。
    Version: 4.2J
    OS: SunOS 4.x, SunOS 5.x, HP-UX 9.x, HP-UX 10.x, Windows 95/98/NT 4.0

    STVOL(プログラム規模)は、下式で表わされます。

      STVOL = n × log2(t)

    ここで n = STTOT(トークンの総数)
          t = t1 + t2

    なお t1 = STOPT(異なった演算子の数)
         t2 = STOPN(区別可能なオペランドの数)

    上式の通り、STVOLは STTOT(トークンの総数)に比例しますが、 STTOT自体は長さの長いトークンも短いトークンもそれぞれ1個として数えたものの総数ですので、ここに「バイト」という概念は入りません。

    また、log2(t) の項が含まれていることからおわかりの通り、 STVOLは行数の長さだけでなく、いかに多くの種類の演算子やオペランドが含まれているか、という点が加味された上で算出されます。これは、多くの種類 の演算子やオペランドが使われている場合は、それだけ難しいコードを作っているという前提に基づいています。トークン数がほぼ同じで、同じ論理を実現する 2種類のプログラムを作った場合、変数の種類を多くしただけで、上式のnの項が増加して、STVOLが増加しますのでお試し下さい。

    ご質問に「バイト換算」という表現がありますが、別に8バイト単位で算出している値ではありませんので、バイト換算も、8で割る必要もないと思われます。

    回答を閉じる

    Qソースコードの行数に関するメトリックスの定義を教えて下さい 。

    A

    代表的なメトリックスの標準値を示します。
    Version: 4.0.3J, 4.2J
    OS: SunOS 4.x, SunOS 5.x, HP-UX 9.x, HP-UX 10.x, Windows 95/98/NT 4.0

    行数の計算に関するPRL情報です。

    [フ]=ファイル・メトリックス
    [関]=関数メトリックス

    [フ]STTPP プリプロセス前の行数
    ファイル適用範囲にあるファイル内のソースコードの総行数
    [フ]STTLN プリプロセス後の行数プリプロセスを経て、マクロ定義等を展開した後の総行数
    [関]STLIN 保守可能なコード行数
    空白行、コメントや大カッコのみの行を含まない関数の定義部分の行数
    関数内('{'と'}'の間)に書かれている全ての行数
    [関]STXLN 実行コード行数
    STLINから宣言部分を除いた行数
    関数内の全ての実行行を数えたもので、以下のものは数えません。
    ※コメントのみの行、空行、'{'または'}'のみの行、宣言行

    以下は、PRLが作ったテクニカルガイドの抜粋です。
    M11 コード行数 CANTATA
    QA C
    QA C++
    McCabe
    関数ベースとファイルベース
    関数ベース
    関数ベース
    関数ベース
    (尺度:絶対値 単位:行)
    CANTATAではコード行数のことを関数ベースの時には CODE_LINESと呼び、 ファイルベースの時には FILE_CODE_LINESと名づけています。
    コード行数は、関数の最初の大カッコから最後の大カッコまでの行数と変数宣言部分の行数を含んでいます。
    関数ベースでは、QA Cや QA C++はこのコード行数のことを STLINと名づけており、空白行、コメントのみの行、 大カッコのみの行は含まない関数の定義部分の行数として数えます。
    4つツール全て、計算はプリプロセス前のコードに対してなされます。
    CANTATAによってなされる計算はMcCabeによってなされる計算と同じです。 しかし、QA CとQA C++では計算方法が異なっているので矛盾が生じます。
    M11が200を超えるものについて全ての関数を調査してください。 200行より小さく、かつ十分に空白行やコメントがあるような関数を書いてください。 スペースを追加することが可読性を上げるのかどうか評価するにはM11を使ってください。
     
    M13 実行行数 QA C
    QA C++
    McCabe
    関数ベース
    関数ベース
    関数ベース
    (尺度:絶対値 単位:行)
    QA Cと QA C++ではこの統計値を STXLNと名づけ、各関数について計算します。
    実行行数は M11から宣言の行数を引いた値です。
    多くのコーディング標準は M13は50を超えてはいけないと要求しますが、150という限界値の方が現実的です。
    もし関数の実行行数が150以上なら、関数を調査し、M13を150以下にするように関数を修正してください。
    なぜそうなったかという明らかな技術的理由がある場合には、責任者に品質に関して譲歩する許可をもらい、 コードが標準に満たないで譲歩しているものだというドキュメントをつけてください。
     
    M15 プリプロセス前のソース行数 CANTATA
    QA C++
    McCabe
    関数ベースとファイルベース
    ファイルベース
    関数ベース
    (単位:行)
    M15はファイル中のプリプロセス前のソースコードの総行数のことです。
    QA Cと QA C++ではこの値はファイルの適用範囲で計算し、STTPPと名づけています。
    CANTATAではこの値をファイルの適用範囲では FILE_SOURCE_LINESと名づけ、 関数の適用範囲ではSOURCE_LINESと名づけています。
    この値はファイル適用範囲のファイルのソース総行数か関数適用範囲内の関数の総行数です。
    M15はユーザが書いたコードの大きさを測定するもので、多くの方法論で(例えば、 COCOMOコストモデル)コードの外部属性の予測要因として使用されます。 例えば、ライフサイクルの後半段階で必要な時間や労力といったものです。
    研究は、広い範囲にわたり単体の測定値でなく使用されている製品の測定値の方が、 工程や資源の測定値を予測をするには一貫し てM15より有益だと示しています。
    しかしながら1つの製品の測定値を該当する工程や資源の測定値の一般的な予測要因として使用することは あまりお勧めできません。
    コードがプロセッサに依存しているかどうかを評価するには M16と M15を使ってください。
    もし、後半の工程や資源の測定値を予想しなければいけない時には、 このガイドに記述している他の測定値よりはむしろM15の予測値を基本にしてください。
    ただし、この予測値は特に優れた予測要因ではないことに注意してください。
     
    M16 プリプロセス後のソース行数 QA C
    QA C++
    ファイルベース
    ファイルベース
    (尺度:絶対値 単位:行)
    M16はファイル中のプリプロセス後のソースコードの総行数のことです。
    M16自身ではとくに測定値としては使用しません。 しかしながら、コードがプロセッサに依存しているかどうか評価する時には M15と合わせて使用します。
    Cではプロセッサへの依存が高いと、コードの移植性が悪くなります。
    C++ではコンパイラが型のチェックをすることができない構築子の使用の前兆でもあります。
    M16/M15は4を超えてはいけません。もし4を超えてしまったらコードはプロセッサに依存しすぎだといえます。
    そのようなコードやM16やM15がきわめて高い値を示しているコードは プロセッサに依存していることから生じる潜在的な問題がないかどうか調べてください。 そして、見つかった明らかな問題点はすべて修正してください。

     

    回答を閉じる

    QSTSCT、および STECTのカウント方法を教えてください。

    A

    宣言した静的変数の数、宣言した外部参照変数の数をカウントします。
    Version: 4.2J
    OS: SunOS 4.x, SunOS 5.x, HP-UX 9.x, HP-UX 10.x, Windows 95/98/NT 4.0

    静的変数の総数 (STSCT) は、ファイルスコープで static という記憶クラス指定子を使用して宣言されている識別子 (変数、関数) の数です。

    また、宣言した外部変数の総数が、STECTとしてカウントされます。

    前者、後者のメトリックとも1つのファイルが有効範囲(スコープ)です。
    外部変数の場合、同じ変数名でいくつのファイルに宣言されている場合、それぞれのファイルで STECTにカウントされます。

    また、オプション -ppm(メトリックスを測定するタイミングをプリプロセスの前後どちらにするか指定するオプション)の設定によって、これらの値は変化します。

    -ppm-の場合(メトリックスをプリプロセス前に測定)

      宣言されている静的変数の総数 (STSCT) 1
       宣言されている外部変数の総数 (STECT) 2

    -ppm-の場合(メトリックスをプリプロセス後に測定)

      宣言されている静的変数の総数 (STSCT) 3
       宣言されている外部変数の総数 (STECT) 3

    (例)

    test.h

    1: int DDD;
    2: static int EEE;
    3: static int bar(void);

    test.c

    8: #include "test.h"
    9:
    10: static int AAA;
    11: extern int BBB;
    12: int CCC;
    13:
    14: int foo(void);
    15:
    16: int foo(void)
    17: {
    18:  static int x;  /* 関数スコープの static識別子は数えない */
    19:
    20:  return 1;
    21: }

    回答を閉じる

    FAQ一覧へ戻る