バージョン管理の活用

Altium NEXUSは、Subversion (SVN)、およびGitバージョンコントロールシステム (VCS) を対応しています。これらのシステムを対応しているため、Altium NEXUS内でコミット、更新等のSVN/Gitファイルを扱う一般的なコマンドを利用でき、加えてSVNリポジトリの作成等のその他のSubversion機能にも対応します。これにより回路図とPCBの比較機能を統合し、回路図、あるいはPCBドキュメントの2種類のレビジョン間の差分を素早く比較、特定することが簡単になり、PCB設計において、Altium NEXUSの共同作業機能を使用して発生する同時レビジョンの競合を解決します。

設計プロジェクトでバージョンコントロールを使用する前に幾つかの予備的なステップが必要です。基本的なステップは以下の通りです:

• VCSプロバイダ - SVN、およびVCSプロバイダ - Git拡張機能がAltium NEXUSにインストールされていることを確かめます。これらはデフォルトでインストールされますが、ソフトウェアのExtensions and Updates画面でアクセスすることもできます。
• SVNバージョンコントロールが、PreferencesダイアログのData Management - Version Controlページで有効になっていることを確認します。
• SVNデザインリポジトリを選択、および/または作成し、Altium NEXUSとの接続を設定します。GitリポジトリはAltium NEXUSの外部で扱われます。

► SVNリポジトリの作成や接続に関する詳細情報は、VCS Repositoriesをご覧ください。

バージョンコントロールの利用

VCS関連の動作は、Altium NEXUSのProjectsやStorage Managerパネルで行え、後者はその他のVCSコマンドや情報を直接、アクセスできます。Altium NEXUSで開いたとき、パネルにはプロジェクトドキュメント、および関連したVCSの状態が表示されます。

パネルは、ワークスペースの右下にある ボタンメニューから、あるいはメインメニューのView » Panelsから開くことができます。

Projectsパネル

Projectsパネルには、Altium NEXUSで現在、開いている全てのプロジェクトや、プロジェクトを構成するドキュメント、各ファイルのバージョンコントロールの状態が表示されます。

パネル内のVCSファイルのステータスは、バージョンコントロール システムが検出した特定のファイルの状態に関連する一連のアイコンによって表示されます。各ファイルの状態は、一般的に言って、リンクされたリポジトリ内のバージョンコントロール下にある同等のファイルと関連付けられます。ProjectsパネルでのVCSコマンドは、パネル内で右クリックして表示されるメニューのVersion Controlオプションから利用できます。

Storage Managerパネル

Storage Managerパネルでは、ファイルストレージにある豊富なドキュメントを表示し、ローカルドキュメントの履歴機能やバージョンコントロールのステータス/コマンドを利用できます。

パネルのVCSファイルのステータスは、バージョンコントロール システムが検出した特定のファイルの状態に関連する一連の記述、および適用されるアイコンによって表示されます。各ファイルのステータスは、一般的に言って、リンクされたリポジトリ内でバージョンコントロール下にある同等のファイルと関連付けられます。

Storage ManagerパネルでのVCSコマンドは、右クリックメニューで利用できます。特定のファイルでVCSの動作を実行するためには、パネル内のエントリ上で右クリックし、必要なコマンド – 例えば、Commit、Update、Resolve conflict等を選択します。Storage Managerパネルには、パネルの下部の項目にタイムスタンプされたストリーム形式の詳細なVCS、および履歴イベントが含まれています。

バージョンコントロールのステータス

バージョンコントロール下にある各ファイルの現在のVCSステータスが、Projects、およびStorage Managerパネル内に表示されます。

バージョンコントロール システムは基本的に作業フォルダのファイルを監視し、デザインリポジトリ内の対応するファイルと比較します。Altium NEXUSは、VCSインターフェースを通してバージョンコントロール システムとの間で情報を要求・交換し、比較ファイルのステータスに応じて対応します。実際に、これは様々なVCSアラートを通し、さらに利用可能なファイル管理コマンドの適切な変更によって、ProjectsやStorage Managerパネルにファイルアイコンで示されます。

アイコン、およびその意味は以下の通りです:

[blank]		ファイルは、VCSリポジトリのバージョンコントロール下にありません。
	No modification	ファイルのローカルコピーがリポジトリのファイルと一致しており、更新されています。
	Scheduled for Addition	ファイルは、バージョンコントロールに追加されていますが、まだ、VCSリポジトリにコミットされていません。
	Modified	ファイルのローカルコピーはAltium NEXUSで改訂され、作業フォルダに保存されました。ファイルをコミットしてリポジトリに新しいレビジョンを作成してください。
	Out of date	(作業フォルダの) ファイルのローカルコピーはリポジトリ内の対応するファイルより古いため、out of dateの状態です。VCS Updateオプションを使用してリポジトリから最新のファイルを取得するか、ファイルを保存します (不一致状況が生じます)。
	Conflict	該当ファイルの編集・保存されたバージョンにコミットする前に、他のAltium NEXUSユーザーによってファイルがコミットされました。Update、Revert、Resolve CVSオプションを使用して、どのバージョンのファイルをリポジトリの最新のレビジョンにするか決めます。
	Ahead of server (Git)	ローカル作業リポジトリのファイルは、リモートGitリポジトリ内の対応するファイルより新しいものです。これはローカルのファイルがローカルリポジトリに改訂、保存、およびコミットされましたが、まだリモートリポジトリにPushedされていないときに生じます。
	Scheduled for Deletion	プロジェクトファイルはAltium NEXUSのバージョンコントロールから削除され、コミットプロセスの間にVCSリポジトリとデータベースからも削除されます。このアイコンは、ファイルが移植されたローカルの作業フォルダに見つからない ‐ 削除された、名前が変更された、移動された - ときにも使用されます。この状態は、VCS Updateコマンドによりフォルダをリポジトリから再度、移植することで解決できます。
	Locked	ファイルが自分、あるいは他のユーザによりロックされています。自分でロックした場合、(強制的にアンロックした場合を除き) 他のユーザがリポジトリのファイルを新しいレビジョンに更新することはできません。アイコンタイプを使用してロックされたファイルにフラグが付けられ、そのテキストは、誰がファイルをロックしたか –  Locked by me、または Locked by someone elseが示されます。また、VCSテキストは、複数の状態も表示されます (例; Modified and locked by me)。

SVNバージョンコントロールへの追加

Projects、またはStorage Managerパネルのどちらからでも、コマンドを使用して、ファイルを登録し追加してからVCSにコミットし、プロジェクトファイルをバージョンコントロール リポジトリに追加することができます。

以下に記載されるプロセスはProjectsパネルを使用しており、簡単で便利ですが、Storage ManagerパネルではVCSの詳細や各種オプションが用意されていることにご注意ください。

プロジェクトの追加

プロジェクトとその構成ドキュメントをバージョンコントロールに追加するもっと直接的な方法は、プロジェクトフォルダ全体をVCSリポジトリに追加することです。これを行うには、Projects (または、Storage Manager) パネルで右クリックして表示されるメニューからAdd Project Folder to Version Controlコマンドを選択します。

以下のAdd to Version Controlダイアログには、ターゲットとなるデザインリポジトリとサブフォルダを選択するオプションがあります。 ボタンを使用して、ソースプロジェクト フォルダの名前と一致するリポジトリ サブフォルダを自動的に作成できます – をクリックして設定を確定します。続けて、このダイアログには、選択したプロジェクト構成と共にファイルソースフォルダから派生したファイルが表示されます – 必要であれば、チェックボックスの有効/無効を用いて含めるファイルを選択します。

を選択して、選択を確定します – Projectsパネル内のファイルのステータスがScheduled for addition ()になっていることに注意してください。これは、VCSがバージョンコントロールへの追加のためにファイルを登録し、VCSリポジトリへのチェックイン (コミット) の準備ができていることを表しています。

プロジェクトのコミット

ステータスがScheduled for addition ()となっているファイルは、コミットした時点でバージョンコントロールとデザインリポジトリに追加されます。これを行うには、Projectsパネルで右クリックして表示されるメニューからCommit Whole Projectコマンドを選択します。

続くAdd to Version Controlダイアログで、個々のプロジェクトファイルについて、バージョンコントロール下に含めるかどうかの選択を取り消す (または、選択を追加する) ことができます。コメントも追加することができ、その後、VCSレリビジョンの更新時に反映されます。

続けて、プロジェクト、およびその構成デザインドキュメントはVCSリポジトリにコピーされ、新しいレビジョンとしてVCSリポジトリに登録され、Altium NEXUSのパネル内のファイルのステータスはNo Modification ()に変わります。

新しいリビジョンに関するさらに詳しい情報を得るためには、いずれかのプロジェクト ドキュメントを編集用として開き、Storage Managerパネルからファイルを選択します。パネルの下部に、選択されたファイルのレビジョン履歴とローカルドキュメント履歴が表示されます。あるいは、’classic view’ に切り替えると (右クリックオプションからSwitch to Classic Viewを選択)、イベントの全体的な時系列を見ることができます。VCSのコミット毎に表示されるレビジョン番号はインクリメントされ、最初のレビジョン (Revision 1) はVCSプロジェクトフォルダ作成時のものとなり、その後に追加されるファイルが続きます。

Gitバージョンコントロールへ追加

Gitは分散型バージョンコントロール システムであるため、GitのワークフローはSVNと異なっていますが、Altium NEXUSで作成したプロジェクトを作業する場合にその違いはごくわずかなものです。簡単に言うと、Gitは、1つのリポジトリターゲットの依存にフォーカスするよりも、複数のリポジトリ間でデータを伝達します。

► さらに詳しい情報は、Gitのwebサイトを、適用される原則の概要はVersion Control Essentialsをご覧ください。

Git VCSシステムは一般的に、必要に応じて複数のGitリポジトリを管理することができる、集中管理型のリモートGitサーバをベースとしています。高速、軽量の特徴を持つGitは、各プロジェクト用のリモートリポジトリを作成する作業に適しており、作成されたリポジトリは、その後プロジェクトに携わるどのユーザに対しても作業リポジトリとしてコピーできます。ユーザの作業Gitリポジトリにある更新されたファイルは、その後Gitサーバ上のリモートリポジトリに ‘pushed’ され、同期されます。

GitシステムにおいてAltium NEXUSでのプロジェクトを確立するために使用する方法は、企業のインフラストラクチャや習慣によって異なり、外部のツール、およびプロセスが含まれます。プロセスが一旦バージョンコントロールシステム内に確立されローカルの作業リポジトリとして利用できるようになると、Altium NEXUSでのGit VCSの作業は事実上、SVN VCSを用いた作業と同じことになります。

プロジェクトをGITへ追加

例示されている方法により、既存のAltium NEXUSプロジェクトは、ベーシックGitコマンドライン ツールを使用してローカルGitリポジトリに追加することができます。この方法により、プロジェクトフォルダはローカル (作業) Gitリポジトリとなり、これはリモートGitリポジトリとリンクされ、最新の状態まで更新されます。

ここで、ツールは以下の目的で使用します:

1. プロジェクトフォルダ内に作業Gitリポジトリを作成 (初期化) します。
2. プロジェクトファイルをGitバージョンコントロールに追加します。*.*形式のファイルを追加し、フォルダは追加しません。
3. Webサーバ上の共有リモートGitリポジトリにリンク参照先を指定します。PCrepoは、リモートリポジトリURLの指定されたローカルエイリアスです。

Altium NEXUSでプロジェクトを開くと、Projects、およびStorage Managerパネル内でのファイルのステータスは、Scheduled for Addition ()です。その後、作業リポジトリにコミットされたとき、ファイルのステータスはAhead of Server status ()に 変更されますが、これはファイルがその時点においてリモートGit リポジトリのコントロール下にないためです。

PushコマンドはローカルリポジトリをリモートGitサーバに更新しますが、この際、ターゲットリポジトリに有効な資格証明書が要求されることがあります。CommitとPush操作は、Altium NEXUSの ボタン1つで実行できますが、ここでは説明のため完了までを別個のステップとして記載します。

Altium NEXUSでのプロジェクトは、現在、Gitバージョンコントロール下にあり、リモートGitリポジトリのユーザにも利用できるようになりました。他のユーザはリポジトリを自分のローカルPCにコピーすることが可能であり、例として、編集されたファイルを共同ワークフローのリモートリポジトリに最終的に戻すことができます。

新しい変更をバージョンコントロールへ更新

プロジェクトをバージョンコントロールに追加したとき、そのローカル作業プロジェクトフォルダはVCSリポジトリ内の対応するフォルダにリンクされ、Storage Managerパネル内のプロジェクト フォルダに関連付けられたリンクアイコンで表示されます。リンクされたフォルダとリポジトリの場所を確認するには、パネルのファイルエントリ上で右クリックし、VCS Propertiesオプション (Git使用時は利用できません) を選択します。以下のPropertiesダイアログには、リンクされた場所のパス、および最新のVCSレビジョンに関する情報が含まれています。

   

VCSリンクを登録すると、バージョンコントロール システムはローカル プロジェクトフォルダ内のファイルとVCSリポジトリフォルダにある同等のファイルを監視して、あらゆる差分を検出することができます。Altium NEXUSでデザインファイルを編集、保存した場合のように、差分が検出されると、バージョンコントロール システムによりローカルファイルのステータスがModified ()に変更され、パネルで右クリックしてVCSコマンドを利用できます。

変更のコミット

Altium NEXUSでプロジェクト ドキュメントファイルを編集、保存した後、ファイルにはModifiedフラグが付き、ProjectsとStorage Managerパネルの両方で()と表示されます。これらの変更をVCSで新しいレビジョンとしてコミットするには、パネル内のファイルエントリを右クリックし、メニューからCommitコマンドを選択します。Commit Whole Projectコマンドを使用して、プロジェクトの改訂されたファイルすべてをコミットすることもできます。

• サブバージョン (SVN) 使用時: コミットプロセスは更新されたファイルをローカルフォルダからリポジトリにコピーし、VCSエントリのレビジョン番号をインクリメントし、ファイルステータスをNo Modification ()に戻します。
• Git使用時: コミットプロセスはローカル作業リポジトリVCSを更新し、エントリのレビジョン番号をインクリメントし、ファイルステータスを Ahead of Server ()に設定します。作業リポジトリ内でファイルの編集を継続し、保存、およびコミット、あるいはPushコマンドを使用したリモートGitリポジトリの更新による新たな変更の承認等を行うことができます – ファイルステータスは、No Modification ()に戻ります。

Storage Managerパネルを表示してVCS Revisionsの項目で一連の動作を確認でき、これには、ファイルの新しいVCSレビジョン (レビジョン番号のインクリメントも含む) の作成が含まれます － この場合、Revision 3と追加されたコメント。 アイコンは選択されたファイルの最新の現在のレビジョン、あるいはバージョンコントロールの用語ではHeadレビジョンを表します。

レビジョン、および履歴イベントエントリーの両方をcombined viewで表示するには、右クリックして表示されるメニューからSwitch to Combined Viewを選択して、1つのTime lineビューへ変更します。

バージョンコントロールからチェックアウト

上記概要の通り、バージョンコントロールに追加したローカルプロジェクトは、Altium NEXUSでプロジェクトのローカルフォルダから編集することが可能で、変更はVCSリポジトリに更新されます。ローカルフォルダとリポジトリフォルダはVCSによりリンクされ、最終的に同期します。

ソースフォルダ (自分のPCのローカル) からプロジェクトへアクセスできない他のユーザは、Check Outプロセスを利用して、プロジェクトを管理するSVNリポジトリからファイルのコピーを自分用に取得することができます。プロジェクトデザインで共同作業したいユーザーは、一般にローカルネットワークかサーバからアクセスできるように設定された、汎用、あるいは ’集中管理型’ SVNデザインリポジトリに接続することが必要です。

► デザインリポジトリへのアクセスに関する情報は、VCS Repositoriesをご覧ください。

リポジトリからプロジェクトをチェックアウトするには、Altium NEXUSメインメニューからFile » Check Outを選択します。以下のCheck Outダイアログを使用してドロップダウンメニューから必要なリポジトリを選択するか、またはPreferencesダイアログのData Management – Design Repositoriesページで ボタンを使用して新しいリポジトリ接続を確立します。Check out toオプションを編集して、初期のリポジトリ接続設定で確立したパスを上書きできます。

選択されたリポジトリ プロジェクトフォルダ、およびその構成ファイルは、指定されたローカルフォルダへチェックアウトされ、Altium NEXUSで開きます。このローカルフォルダは選択されたリポジトリのチェックアウト フォルダとして定義されており、チェックアウトされたプロジェクトは続けてSVNリポジトリ内の対応するファイルにリンクされることに注意してください。VCSリンクはバージョンコントロールシステムに対し、ローカル チェックアウト フォルダ内のファイルとVCSリポジトリフォルダ内にあるその同等のファイルを監視して、あらゆる差分を検出するよう指示します。    

ファイル編集が終了したときは変更をコミットして、デザインリポジトリのファイルをチェックアウト フォルダ内のファイルと一致させ、新しいVCSレビジョンを作成します。

チェックアウト 対 プロジェクトを開く

ローカルプロジェクトをバージョンコントロールに追加したとき、編集できる2つの方法があり、VCSに更新することができます:

• Altium NEXUSでローカルプロジェクトを開き (File » Open Project)、次いで保存した変更をVCSリポジトリにコミットする方法。
  この場合、ローカル プロジェクトフォルダとリポジトリ内の対応するファイルはVCSによってリンクされます。
  
• VCSリポジトリからプロジェクトをチェックアウトし (File » Check Out)、次いでAltium NEXUSで保存した変更をコミットしてリポジトリに戻す方法。
  この場合、指定されたチェックアウト フォルダとリポジトリ内の対応するファイルはVCSによってリンクされます。
  

ローカルプロジェクトは、VCSプロジェクトのsourceまたはoriginであり、他のユーザと共有されます。希望する作業の方法に応じて、このローカルのソースバージョンを削除、あるいはアーカイブされたプロジェクトソースとしてロックできます。そして、Check Outしてから編集できます。または、ローカルの 'source' フォルダからプロジェクトファイルを開いて作業することも可能です (Open Project)。

ベストのアプローチは1つの方法だけ (Check Outが推奨されています) を常に使用することです。なぜなら2種類のオプションを使用した場合、異なる場所の作業フォルダ －ローカルソースのプロジェクトフォルダ、および指定されたVCSチェックアウトフォルダを扱うことになるからです。逆に言えば、2種類の方法を使用することにより、ローカルPC上の同一プロジェクトについて複数のアーカイブされたコピーが存在することになります。しかし、これらのバージョンを編集のたびに集中管理型VCSリポジトリへ毎回コミットするなら、リポジトリは意図通り最新のレビジョンを保持することが可能になります。

プロジェクトが初めにVCSリポジトリから一旦、チェックアウトされると、そのプロジェクトはローカルに存在することになり、チェックアウト フォルダから直接、開く (File » Open Project) ことができます。この場合も、プロジェクトをVCSからチェックアウトする (File » Check Out) 方法と、ローカルバージョンを開く (Open Project) 方法の2種類の選択肢がありますが、いずれにしてもローカルコピーは1つだけになります。現実のVCS条件下で2つの方法は非常に類似していますが、幾つかの状況下では異なる挙動を示します－ローカルファイルが見つからない場合、Check Outコマンドではファイルを復活できますが、Open Projetコマンドではファイルがプロジェクトから削除されます。

GITリポジトリのコピー

Gitバージョンコントロールに追加されたローカルプロジェクトは、Altium NEXUSでプロジェクトのローカルフォルダ (作業リポジトリ) から編集し、Gitリポジトリに変更をコミットして更新することが可能です。ローカルのリポジトリとリモートリポジトリは、VCS Pushコマンドによってリンクされ、最終的に同期されます。

デザインで共同作業したい他のユーザは、リモートGitリポジトリをローカル作業リポジトリにコピーすることによって、プロジェクトにアクセスすることができます。Gitリポジトリからファイルへのアクセス方法は企業のシステムや方法によって異なりますが、コンテンツをリモートリポジトリからローカル作業リポジトリにコピーする基本的な方法は、Gitコマンドを使用することです (下図に示すように、git clone [リモートリポジトリURL] [ターゲット作業リポジトリフォルダ])。

このプロセスは、ローカル作業リポジトリとして共有のリモートリポジトリに複製され、最新の (HEAD) レビジョンをマスターブランチから自動的にチェックアウトします。ファイルはその後、Altium NEXUSで編集、保存、VCSにコミットし、最終的にリモートGitリポジトリにpushして戻すことが可能です。

バージョンコントロール レビジョン

Altium NEXUSでバージョンコントロール下にあるデザインドキュメントの作業を行う間、主要 (共有) VCSリポジトリからアクセスするデザインファイルがこれらのファイルの最新レビジョンに相当します。ローカルでの編集が完成し、共有VCSリポジトリに戻したとき (コミット) (Gitの場合; pushed) 、これらのバージョンのファイルが最新レビジョンとなります。

そこで、チェックアウト、編集、保存、およびコミット (Gitでは、Push) の通常の順序は、プロジェクト設計の進行に応じて、新しいファイルのレビジョンが段階的に主要VCSに追加されます。プロジェクトを複数の設計者で共同開発するとき、どの設計者も、いつでも新しいレビジョンを主要 (共有) リポジトリにコミットすることができます。

OUT OF DATEのレビジョン

複数の設計者と主要リポジトリ間のやりとりは多くの方法で現状を表示し、ローカルで開いたプロジェクトが既に最新のレビジョンではない – リポジトリからチェックアウトされた、あるいはローカル作業フォルダから開いたプロジェクトは、ProjectsパネルでOut of date  ()のステータスが示されます。

この場合、他のユーザはプロジェクトが最後にローカルで編集されたため、同一のプロジェクトをリポジトリに編集、およびコミットしています。例えば、下図のStorage Managerパネルで示すように、このプロジェクトで作業するローカルユーザのBarryがコミットして、Revision 14としますが、その後に別のユーザのHaroldがRevision 15をコミットします。VCSはローカル作業フォルダにあるファイルとリポジトリ内の対応するファイル (この場合では、より新しい方) の差分を検出し、システムは最新のローカルレビジョン ( アイコンで示される) をout of dateと判断します。

この状況は、Projects、あるいはStorage Managerパネルで右クリックして表示されるメニューのUpdateコマンドを使用し、ローカルファイルを更新して主要VCSリポジトリに一致させることにより修正できます。これにより2つのファイルバージョンは、(Barryの) ローカルバージョンと同期され、最新のレビジョンバージョン – この例ではRevision 15として更新されます。Out of dateとして分類されているファイルを保存すると、VCSはファイルの古いレビジョンが作業フォルダ内で更新されたと判断するため、VCS Conflictが生じることに注意してください。

レビジョンの不一致

複数の設計者と主要リポジトリ間との相互作用により、2人のAltium NEXUSユーザが、同一のファイルをローカルで編集、保存し、1人がこれらの変更をコミットしたという状況が起きる場合があります。

これは、1人の設計者による一連のステップ (チェックアウト、編集、保存、コミット) が他の設計者のステップと重なったことを意味し、ユーザが編集のためにリポジトリからチェックアウトしたファイルは、作業している間 (他のユーザがその間にレビジョンを更新)、最新のレビジョンとしては存在しません。この場合、リポジトリからの編集を最初にコミットした設計者が、新しいレビジョンの作成によって優先され、他のユーザが同一のファイルを編集・保存した場合にConflictが生じることになります – これは、 アイコンで表示されます。

作業フォルダのファイルとリポジトリファイルを比較するVCSから見ると、Conflictは作業フォルダ内にあるout of dateレビジョンのファイルが編集・保存された状態を表すものです。

Storage Managerパネルでは、ファイルのステータスがConflictとなった場合に使用できるコマンドが複数、用意されています:

• Commit - このオプションは、ローカルで編集されたレビジョン (Revision 15) が、他のユーザーがコミットしたより新しいレビジョン (Revision 16) を上書きしようとするために、Subversionエラーを引き起こします。
• Update - このオプションは、ローカルファイル レビジョンを主要リポジトリ (Revision 16) から最新のバージョンに更新し、これによりRevision 15に加えられた変更はすべて失われます。
• Resolve Conflict - このオプションは作業フォルダ内のファイルを最新レビジョン (Revision 16) に更新しますが、編集者の加えた変更 (更新前のRevision 15) を引き続き保持することが可能です。ローカルファイルのステータスはModifiedになり、変更を新しいレビジョン (Revision 17) にコミットすることが可能になります。新しいレビジョンが作成されたため、この後、他のユーザがこのファイルを見るとOut of dateが表示されます。
• Revert - このオプションではローカルの変更が破棄され (Undo)、ローカルファイルを元のレビジョン (ここでは、Revision 15) に戻します。これにより、レビジョンの不一致は解決しますが、より新しいレビジョン (Revision 16) がリポジトリ内に存在するため、ファイルはOut of dateと表示されます。

要約すると、パネルのConflictオプションにより、最新のファイルレビジョンを選択 (Update)、新しいレビジョンを作成 (Resolve Conflict)、あるいはローカルの編集を破棄 (Revert) のいずれかの方法を実行できます。

レビジョンの比較

バージョンコントロールで作業する重要な利点は、デザインファイルの履歴レビジョンを比較する機能です。この機能はAltium NEXUSに内蔵された相違コンパレータに含まれ、Storage Managerパネルからアクセスできます。Differencesパネルと共に使用する場合、VCSレビジョン間の論理、およびグラフィカルを比較し、同時に影響を受けるオブジェクトを相互に確認することができます。回路図とPCBのレビジョン両方を比較することができます。

2つのレビジョン間の比較を開始するには、Storage ManagerパネルのVCS Revisionsリストで両方のエントリを選択し (標準のCtrl+クリックを使用)、パネルで右クリックして表示されるメニューからCompareコマンドを選択します。

両方のファイルレビジョンがAltium NEXUSの分割スクリーンモードで開き、視覚的に比較することができます。どの相違を表示するかは、Options for Projectダイアログ (Project » Project Options) のComparatorタブ内のPhysical比較タイプを選択して決定することができます。

相違の位置を特定して表示、比較するために、Differencesパネル内に、ドキュメント間の論理的、あるいはグラフィカルな相違を選択して表示するリストがあります。このパネルにリストアップされた各ドキュメント レビジョンのエントリはエディタとリンクしており、検出された相違 (オブジェクトの移動等) を選択すると視覚的にハイライトすることができます。

Compare機能はPCBドキュメントのレビジョンだけでなく、回路図、およびテキストベースのドキュメントでも使用することができます。

Compareコマンドは、現行のローカルレビジョン (作業フォルダ内) とリポジトリ内のより新しいレビジョンの比較を含め、どんな組み合わせについても使用することができます。この場合、最新のローカルレビジョンはStorage Managerパネル内でOut of date ()と表示されますが、他のユーザがリポジトリに追加した新しいレビジョンと比較することができます。

この方法により、新しいレビジョンへの更新によって発生する変化を視覚的に確認できます。上図の例では、現行のローカルレビジョン ( アイコンで表示) はRevision 19ですが、他のユーザが新しいレビジョンをリポジトリにコミット (Revision 22) しました。Revision 19とRevision 22を視覚的に比較して調査することにより、新しい変更をリポジトリから受け入れるかどうかについて、十分な情報を得てから決定を下すことができます。また、表示される情報を参考にして、Updateコマンドの実行やConflictを引き起こすことによる拒否を適用するかどうか決定することもできます(ローカルファイルの再保存、およびローカルレビジョンの選択によるconflictの解決を通して)。