Using External Version Control with Altium Designer

電子的な作成および編集環境の最大の強みの一つは、ファイルを作成および変更することの容易さです。この機能により、アイデアを迅速にキャプチャし、探求し、成熟させることができますが、ソースコードや電子設計データなどの貴重なファイルに加えられた変更を追跡することが難しいことも意味します。

ファイルに加えられた変更を追跡する必要性と、電子形式でキャプチャされたソースを管理するための体系的なソリューションの必要性が、バージョン管理システム（VCS）の登場につながりました。バージョン管理システムは、ファイルのさまざまなバージョンの履歴を維持するだけでなく、そのファイルの任意のリビジョンを開いたり、ファイルの2つのバージョン間で行われた変更を比較したりすることもサポートするソフトウェアツールです。VCSは一般に、フォルダやファイルに対する追加のバージョニング機能と操作を提供することにより、ローカルのオペレーティングシステム（OS）と統合します。

バージョン管理システムは、ファイルを作成するために使用される作成および編集環境とは完全に独立して操作できます。これらは通常、ファイルをリポジトリと呼ばれる中央のストレージエリアに追加してコミットするインターフェースを提供し、リポジトリから作業フォルダにファイルをコピーするチェックアウト機能、リポジトリに変更をチェックバックインするコミット機能、変更に関する情報のログ方法などを提供します。

これらの機能は、TortoiseクライアントなどのWindowsシェル拡張機能に見られ、Altium Designer自体にも含まれています。VCS操作は、OSファイルシステムにアクセスすることなく、Altium Designer環境内で実行できます。

バージョン管理システムで使用される用語を理解することは役立ちます。利用可能なシステムが数多くあるにもかかわらず、一般的には機能を説明するために類似の用語を使用しています。

バージョン管理の基本

Altium Designerは、Subversion（SVN）およびGitバージョン管理システム（VCS）をサポートしています。これらのシステムに対する内部サポートがあるため、Altium Designer内でコミット、更新などの一般的なSVN/Gitファイル処理コマンドにアクセスできるだけでなく、SVNリポジトリを作成するなどの追加のSubversion機能を提供します。これは、回路図およびPCBの比較機能と統合されており、2つのリビジョンの回路図またはPCBドキュメント間の違いを迅速に比較して特定し、PCB設計の場合は、同時リビジョンの競合を解決するのに役立ちます。

バージョン管理システム（VCS）を使用して作業する基本的なアプローチは、リポジトリから作業したいプロジェクトファイルのコピーにアクセスし、Altium Designerでファイルを編集してから、変更されたファイルをリポジトリに「コミット」することです。リポジトリとのやり取りは、バージョン管理システムインターフェースを介して行われ、Altium Designerはそのストレージマネージャーパネルおよびプロジェクトパネルに組み込まれています。

バージョン管理システムの動作の鍵は、リポジトリからアクセスされたファイルの状態を監視し、作業フォルダを介して、どのリビジョンが作業されているか、およびそれが変更されたかどうかを追跡することです。結果は同じですが、リポジトリと作業ファイルの配置は、バージョン管理システムのタイプによって異なります - GitまたはSVN。

Git VCS

下の図は、リモートGitリポジトリの共有概念を示しており、設計ファイルの改訂（改訂5まで）のシーケンスを保持しています。その内容はローカルの作業Gitリポジトリにコピーされており、通常はリモートリポジトリをクローンするか、そのデータを作業リポジトリにプルすることによって行われます。作業リポジトリ内のファイルがAltium Designer環境で開かれると、Altium DesignerはプロジェクトファイルがGitバージョン管理下にあることを認識し、現在のバージョン管理ステータスがStorage ManagerおよびProjectsパネルの両方に表示されます。

► 詳細については、Gitベースのバージョン管理ページを参照してください。

VCSサブバージョン

下の図は、設計ファイルのリビジョン（リビジョン5まで）のシーケンスを保持するサブバージョンリポジトリの概念を示しており、最新のコピーが作業フォルダーにチェックアウトされています（File » Check Out）。作業フォルダー内のファイルがアルティウムデザイナー環境で開かれると、アルティウムデザイナーはプロジェクトファイルがSVNバージョン管理下にあることを認識し、その現在のバージョン管理状況がStorage ManagerとProjectsパネルの両方に表示されます。

► さらなる情報については、SVNベースのバージョン管理ページをご覧ください。

上記の両方のVCSシステムでは、ソースリポジトリと作業場所の間のリンクが、後者のVCSデータベース（.svnまたは.gitシステムサブフォルダー内）で参照されています。

VCS作業ファイルがAltium Designerで開いているとき、Storage Manageパネル（およびProjectsパネル）の右クリックメニューからは、変更したファイルを中央リポジトリ（SVN）や作業リポジトリ（Git）にコミットするなどの標準VCSアクションを実行できます。

バージョン管理アクセス

Altium Designerでは、VCS関連のアクションはProjectsおよびStorage Managerパネルを通じて実行でき、後者は追加のVCSコマンドや情報に直接アクセスを提供します。パネルは、Altium Designerで開いた際にプロジェクト文書とそれに関連するVCSステータスで満たされます。

パネルは、作業スペースの右下のボタンメニューまたはメインのView » Panelsメニューから開くことができます。

Projectsパネル

Projectsパネルは、Altium Designerで現在オープンしているすべてのプロジェクトと、それに含まれるドキュメント、各ファイルのバージョン管理ステータスを表示します。

パネル内のVCSファイルステータスは、バージョン管理システムによって検出された特定のファイル条件に関連する一連のアイコンを通じて示されます。各ファイルの状態は、一般的にはリンクされたリポジトリ内のバージョン管理されている同等のファイルに対して相対的です。Projectsパネル内のVCSコマンドは、パネルの右クリックコンテキストメニューのVersion Controlオプションからアクセスされます。

Projectsパネルに表示されるバージョン管理アイコン

► 詳細についてはProjectsパネルのページをご覧ください。

Storage Managerパネル

Storage Managerパネルは、ファイルストレージの観点からアクティブなドキュメントの豊富なビューを提供し、ローカルドキュメントの履歴機能とバージョン管理の状態/コマンドにアクセスできます。

パネル内のVCSファイルの状態は、バージョン管理システムによって検出された特定のファイル条件に関連する一連の説明と一致するアイコンを通じて示されます。各ファイルの状態は、一般的に、リンクされたリポジトリ内に存在する同等のファイルに対して相対的です。

Storage Managerパネル

Storage ManagerパネルのVCSコマンドは、右クリックコンテキストメニューからアクセスされます。特定のファイルに対してVCSアクションを実行するには、パネル内のそのエントリを右クリックし、希望するコマンド（たとえば、コミット、更新、競合解決など）を選択します。

選択されたファイルの履歴とローカルドキュメントの履歴は、パネルの下部に表示されるか、"クラシックビュー"に切り替えると全体のタイムラインが表示されます - 右クリックオプションのSwitch to Classic Viewを使用します。指定されたリビジョン番号は、各VCSコミットごとに増加し、最初のリビジョン（リビジョン1）は、ファイルが追加される前のVCSプロジェクトフォルダーの作成に対応します。

► 詳細については、Storage Managerパネルページを参照してください。

バージョン管理のステータス

ProjectsおよびStorage Managerパネルの両方において、バージョン管理の下にある各ファイルの現在のVCSステータスがパネル内のエントリとともに表示されます。

バージョン管理システムは、基本的に作業フォルダー内のファイルと設計リポジトリ内の対応するファイルを監視し、比較します。Altium DesignerはVCSインターフェイスを介してバージョン管理システムに情報をリクエストし、交換し、比較結果のファイル状況に応じて応答します。実際には、これがProjectsおよびStorage Managerパネルのファイルアイコンや一連のVCSアラート、そして利用可能なファイル管理コマンドの適切な変更として現れます。

アイコンとその意味は、プロジェクト文書の管理ページのバージョン管理ステータスアイコンセクションで説明されています。

複数ユーザーアクセス

ほとんどの状況において、企業のバージョン管理インフラストラクチャは、ネットワーク経由で利用可能なプロトコル方式（svn、svn+ssh、httpsなど）を使用して提供される中央のSVNまたはGitリポジトリに基づいています。これにより、権限に応じてネットワーク上のすべてのユーザーがアクセスでき、単一のソースからの共同プロジェクト開発の手段が提供されます。

その結果、複数のアクセス機能によって、異なるチームメンバーがファイルのチェックインを他の誰かが行うのを待つことなく、プロジェクトに独立して取り組み続けることができます。分散型Gitバージョン管理システムは、この利点をさらに一歩進め、作業を進める中でローカル作業リポジトリにファイルをコミットでき、コミットした変更を後に中央のGitリポジトリに‘プッシュ’することができるため、その時点まではネットワーク接続を必要としません。

それでも、チームに適合するVCSは、2人のユーザーが同じファイルを変更したという避けがたい状況を解決するためのツールと技術が利用可能であることが必要です。これらの機能が利用できると、真のマルチユーザー設計コラボレーションとそれに伴う利点の基盤が整います。

この状況をサポートするために、Altium Designerには、Storage Managerパネルを通じて利用可能な回路図とPCBの比較（または「diff」）機能が含まれています。

VCSリポジトリ

既知のソースファイルセットから作業する最良の方法は、デザインプロジェクトをバージョン管理リポジトリなどの制御された環境に保存することです。これは重要であり、出力が正しいソースファイルから来ることを保証する唯一の方法は次の通りです：

1. ソースファイルセットが最新であることを確認してください。

2. それらのスナップショットを撮ってください。

3. そのスナップショットから出力を生成します。

Altium Designerでは、そのようなリポジトリを設計リポジトリと呼びます。設計チームが所有する設計リポジトリは、設計プロセスの履歴の高解像度ビューを含み、設計チームが使用する主要なコラボレーションツールです。

デザインリポジトリは、複数のチームメンバーがデータのチェックインとチェックアウトを行うための中央リポジトリとなり、デザインに加えられたすべての変更の完全な改訂履歴を保持します。したがって、デザインは構成プロジェクトとソース文書の一連のバージョンとして保存され、デザイナーの意図の進捗を時系列で描写します。バージョン管理されたデザインリポジトリを使用することで、デザインの改訂が決して失われないという確実性が得られ、安全に地理的に分散したチームメンバー間で同じデザインの共同作業が可能となります。バージョン管理システムの特性により、デザインの監査証跡が提供されます。誰が何を、どのソース文書で、いつ変更したかの透明性によって完全な説明責任が生まれます。このシステムは、特定のリポジトリへのリンクがプロジェクトフォルダ内のバージョン管理リンクによって確立されることで、複数のバージョン管理されたデザインリポジトリをサポートできます。

バージョン管理を使用する前に、プロジェクトファイルはVCSとAltium Designerの両方によってバージョン管理下にあることが認識されなければなりません。このプロセスはさまざまなVCSメソッドやアプリケーションによって異なる場合がありますが、基本的にはデザインリポジトリを作成および/または接続し、そのリポジトリにデザインプロジェクトファイルを追加することを含みます。

デザインリポジトリはデータベース構造に基づいており、内部的にファイルツリーと呼ばれるファイルやディレクトリの階層で情報を保存しています。実際に接続するリポジトリは、中央のSVNリポジトリ、リモートGitリポジトリに関連付けられたGit作業リポジトリ、またはローカルPCや共有ネットワーク上のアクセス可能な場所に作成したリポジトリのいずれかです。

接続されたワークスペースVCS

バージョン管理下でプロジェクトに取り組む最も先進的な形態は、接続されたワークスペースの機能を活用することです。ワークスペースは、簡素化されたワークフローとストレージ、強化されたコラボレーション機能などを提供するプロジェクトの高度な構造を提供します。

ワークスペース内の対象VCSリポジトリは、ワークスペースおよびAltium Designer（サインイン時）と密接に統合されており、別々のVCSリポジトリを設定および構成する必要がありません。ユーザーアクセス、リポジトリの内容、プロジェクトのステータスは、ワークスペースブラウザインターフェースを通じて管理できます。

バージョン管理への新しい変更の更新

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

リンクアイコンによって示されたファイルと、最新のVCSリビジョンに関する情報を含むPropertiesパネル

Propertiesダイアログには以下の情報が表示されます（この情報は表示専用であり、編集はできません）:

• Path - 作業フォルダー内のローカルドキュメントへのパスです。

• URL - VCSリポジトリ内のドキュメントの場所に関するURL。

• Repository Root - リポジトリのルート。

• Repository UUID - リポジトリUUID。

• Revision - ローカル作業フォルダー内の文書の現在の改訂版。

• Last Change Author - 最後の変更の著者。

• Last Change Revision - 最後の変更の改訂

• Last Change Time - 最終変更の日付と時刻。

• Conflicted - 文書が対立しているかどうか。

登録されたVCSリンクの結果として、バージョン管理システムはローカルプロジェクトフォルダー内のファイルとVCSリポジトリフォルダー内の対応ファイルとの間の違いを監視・検出できます。デザインファイルがAltium Designerで編集されて保存された場合などの違いが検出されると、バージョン管理システムはローカルファイルのステータスをModified ()に変更し、Altium Designerはパネルの右クリックメニューに適切なVCSコマンドセットを提供します。

変更のコミット

プロジェクトドキュメントファイルがAltium Designerで編集され保存されると、Modifiedとしてフラグが立てられ、プロジェクトおよびストレージマネージャーパネルの両方にその旨  ()が表示されます。変更をVCSの新しいリビジョンとしてコミットするには、パネル内のファイルエントリを右クリックし、コンテキストメニューからCommitコマンドを選択するか、メインメニューからProject » History & Version Control » Commitコマンドを選択します。

Commitコマンド

Commit Whole Projectコマンドも使用でき、プロジェクト内のすべての修正されたファイルをコミットします。プロジェクト全体をコミットする際には、Commit to Version Controlダイアログが開きます。

Commit to Version Controlダイアログ

• When using Subversion (SVN): コミットプロセスは、ローカルフォルダーからリポジトリに更新されたファイルをコピーし、VCSエントリのリビジョン番号をインクリメントし、ファイルの状態をNo Modification ()に戻します。

• When using Git: コミットプロセスは、エントリーのリビジョン番号を増加させ、ファイルのステータスをサーバーに対してAhead of Server ()に設定しながら、ローカル作業リポジトリのVCSを更新します。作業リポジトリ内でファイルを編集、保存、コミットし続けることができるほか、Pushコマンドを使用してリモートGitリポジトリを更新することで新しい変更を承認することもできます。この場合、ファイルのステータスはNo Modification ()に戻ります。

Storage Managerパネルを表示して、VCS Revisionsセクションのアクションのシーケンスを確認します。これには、そのファイルの新しいVCSリビジョン（番号が増加したリビジョン番号）の作成が含まれます。この場合、リビジョン3とその追加コメントです。アイコンは、選択したファイルの最新かつ現在のリビジョン、またはバージョン管理用語でいうヘッドリビジョンを示します。

Storage ManagerパネルのVCS改訂セクション

修正と履歴イベントエントリの両方の統合ビューを見るには、右クリックのコンテキストメニューからSwitch to Combined Viewを選択して単一のタイムラインビューに変更します。

バージョン管理からチェックアウトする

上記のように、バージョン管理に追加されたローカルプロジェクトは、プロジェクトのローカルフォルダーからAltium Designerによって編集でき、変更はVCSリポジトリに更新されます。ローカルフォルダーとリポジトリフォルダーはリンクされ、最終的にVCSによって同期されます。

別のユーザーは、プロジェクトのソースフォルダー（あなたのPCにローカルなもの）にアクセスできないため、Clone (Git) や Check Out (SVN) のプロセスを使用して、プロジェクトをホストするVCSリポジトリからファイルのコピーを取得することができます。プロジェクト設計に協力したいすべてのユーザーは、その共通設計リポジトリに接続する必要があります。通常、このリポジトリはローカルネットワークやサーバーを介してアクセスできるように配置されています。

選択されたリポジトリプロジェクトフォルダーおよびその構成ファイルは、指定されたローカルフォルダーにチェックアウトされ、Altium Designerで開かれます。ローカルフォルダーは、選択されたリポジトリのチェックアウトフォルダーとして定義されたものであり、チェックアウトされたプロジェクトは、その後VCSリポジトリ内の対応するプロジェクトにリンクされます。VCSリンクは、バージョン管理システムにローカルチェックアウトフォルダー内のファイルとVCSリポジトリフォルダー内の同等のファイルとの間の差異を監視し、検出するよう指示します。

ファイルの編集が完了したら変更をコミットしてください。これにより、デザインリポジトリのファイルがチェックアウトフォルダのファイルと同期され、新しいVCSのリビジョンが作成されます。

チェックアウトとオープンプログラム

ローカルプロジェクトがバージョン管理に追加された場合、実際にはそれを編集してVCSに更新する方法が2つあります：

• Altium Designerでローカルプロジェクト（File » Open Project）を開き、保存された変更をVCSリポジトリにコミットすることによって、ローカルプロジェクトフォルダとリポジトリ内の対応するフォルダがVCSによってリンクされます。

  

• VCSリポジトリからプロジェクト（File » Check Out）をチェックアウトし、その後Altium Designerで行った保存された変更をリポジトリにコミットします。この場合、指定されたチェックアウトフォルダ内のプロジェクトとリポジトリ内の対応するプロジェクトはVCSによってリンクされています。

  

ローカルプロジェクトは、他のユーザーと共有されているVCSプロジェクトのソースまたは起源です。作業の進め方によっては、このローカルソースのバージョンを削除するか、アーカイブプロジェクトソースとしてロックすることができ、その後、Check Outアプローチを使用してさらに編集することができます。また、ローカルの「ソース」フォルダーからプロジェクトファイルを開いて作業を続けることもできます（Open Project）。

最善のアプローチは、一つの方法（チェックアウトが推奨される）に固執することである。なぜなら、二つのオプションは異なる場所にある作業フォルダーを扱うからであり、ローカルソースプロジェクトフォルダーまたは指定されたVCSチェックアウトフォルダーのいずれかだ。逆に、両方の方法が使用されると、ローカルPC上に同じプロジェクトの複数のアクティブコピーが存在することになる。しかし、これらのバージョンが各編集後に中央集権的なVCSリポジトリに忠実にコミットされると、リポジトリには常にプロジェクトの最新の改訂版が保持されることになる。

プロジェクトがVCSリポジトリから最初にチェックアウトされると、それはローカルに存在し、チェックアウトフォルダから直接再オープンすることができます（File » Open Project）。この場合、VCSからプロジェクトをチェックアウトするか、ローカル版を開くかを選択できますが、ローカルコピーは常に1つだけです。実際のVCSの観点から見ると、2つの方法は非常に似ていますが、いくつかの状況では異なる動作をします。たとえば、ローカルファイルが欠落している場合、チェックアウトプロセスによって復元されますが、プロジェクトからはOpen Projectコマンドによって削除されます。

バージョン管理の改訂

Altium Designerでバージョン管理下の設計文書を作業している際に、中央（共有）VCSリポジトリからアクセスされた設計ファイルは、それらのファイルの最新のリビジョンを表します。ローカルの編集が完了し、共有VCSリポジトリにコミット（またはGitの場合はプッシュ）されると、これらのファイルバージョンは最新のリビジョンとなります。

そのため、チェックアウト、編集、保存、コミット（およびGitでのプッシュ）の通常の手順が、プロジェクトの設計が進むにつれて、中央VCSに新しいファイルの改訂版を段階的に追加します。ただし、いくつかのデザイナーによって共同でプロジェクトが開発されている場合、任意のデザイナーによっていつでも中央（共有）リポジトリに新しい改訂版をコミットできます。

更新日を過ぎた改訂

複数のデザイナーと中央リポジトリとの相互作用は、いくつかの方法で現れることがあります。1つは、ローカルでオープンなプロジェクトがもはや最新のリビジョンではないということです。リポジトリからチェックアウトされたプロジェクトやローカル作業フォルダから開かれたプロジェクトは、ProjectsパネルでOut of date ()というステータスになります。

古いとラベル付けされたファイル

この場合、別のユーザーが最後にローカルで編集されてから同じプロジェクトをリポジトリに編集し、コミットしました。例えば、ローカルユーザーのBarryがプロジェクトに取り組んでおり、Revision 14をコミットしましたが、その後別のユーザーであるHaroldがRevision 15をコミットしています。下に示したストレージマネージャーパネルで確認できます。VCSはローカル作業フォルダー内のファイルとリポジトリ内の対応ファイル（今回は新しいもの）との違いを検出するため、システムは最新のローカルリビジョン（アイコンで示されています）を古いと見なします。

Storage Managerにおける異なるリビジョンステート

Altium Designerの比較機能を使って、ファイルのバージョン間の違いを確認できます。

この状況は、ProjectsまたはStorage Managerパネルの右クリックコンテキストメニューからのUpdateコマンドを使用して、ローカルファイルを中央VCSリポジトリのものに合わせることで修正されます。その後、2つのファイルバージョンが同期され、ローカルバージョン（ユーザーのBarry用）が最新のリビジョンバージョン（この例ではRevision 15）に更新されます。ファイルが古いバージョンとの指定のままSaveされると、VCSが作業フォルダー内のファイルのOut of dateリビジョンが更新されたことを検出し、VCSConflict状況が発生することに注意してください。

Storage Managerにおける中央リポジトリとローカルリビジョン

Update Whole Projectコマンドを選択することで、共有リポジトリからチェックアウトするファイルを選択できるUpdate from Version Controlダイアログにアクセスできます。プロジェクト内のすべての古い文書や衝突を含む文書はダイアログに表示されます。特定の文書を更新するか、すべての文書を一度に更新することを選択できます。選択された文書はリポジトリから更新され、すべての古い文書はデフォルトで選択されます。選択された文書はすべてリポジトリ内の最新バージョンに更新されます。

Update from Version Controlダイアログ

Path列にはファイルディレクトリが表示されます。Status列にはファイルの現在の状態が表示されます。ファイルの状態がConflictとして表示された場合、ファイルを更新するためにOKをクリックすると確認ダイアログが表示されます。リポジトリ内の最新バージョンに更新するにはOKをクリックし、リポジトリ内の現在のバージョンに変更を保存して終了するにはCancelをクリックしてください。

リビジョンの競合

複数のデザイナーと中央リポジトリとの相互作用により、同じファイルが2人のAltium Designerユーザーによってローカルで編集され保存され、1人がその変更をコミットしたという状況が生じることもあります。

これは、一人のデザイナーの手順（チェックアウト、編集、保存、コミット）が別のデザイナーのものと交互になっていることを意味しており、ユーザーが編集のためにリポジトリからチェックアウトしたファイルは、作業中に最新の改訂版として残らない可能性があります。他のユーザーがその間に改訂版を更新したためです。この場合、最初にリポジトリに編集をコミットした人が新しい改訂版を作成し支配しますが、同じファイルを編集して保存した別のユーザーは、アイコンで示されるConflict状況に直面します。

リビジョンの競合例

VCSの観点から見ると、作業フォルダのファイルとリポジトリのファイルを比較する場合、コンフリクトは作業フォルダのファイルの古いリビジョンが編集され、保存された状態を表します。

Storage ManagerパネルにおけるGit VCSリビジョン

ファイルがConflict状態の場合に使用できるいくつかのコマンドオプションが、ProjectsパネルのHistory & Version Controlの右クリックメニュー、Project » History & Version Controlメインメニュー、およびストレージマネージャーパネルからアクセスできます。

• Commit – このオプションはサブバージョンエラーを引き起こします。なぜなら、ローカルで編集されたリビジョン（例えば、Revision 15）をコミットすると、別のユーザーによってすでにコミットされた新しいリビジョン（Revision 16）を上書きしてしまうからです。

• Update – このオプションは、ローカルファイルのリビジョンを中央リポジトリからの最新バージョン（Revision 16）に更新し、その結果、Revision 15に対して行ったローカルの変更は失われます。

• Resolve Conflict – このオプションは、最後に更新して以来リポジトリにコミットされた変更を破棄します。コマンドを起動すると確認ダイアログが表示されますので、続行するにはYesをクリックしてください。作業フォルダ内のプロジェクトファイルは、他のユーザーによってリポジトリにチェックインされた最新のリビジョンに更新されますが、エディタは前のリビジョンに対して行った変更を保持します。したがって、ローカルファイルはModifiedの状態になり、これらの変更をリポジトリ内の新しいリビジョンにコミットできるようになります- CommitコマンドまたはCommit Whole Projectコマンドを使用して。プロジェクトファイルをコミットすると、他のユーザーはリポジトリに新しいリビジョンを作成したため、ファイルはOut of dateと表示されます。

  このオプションは、テキストファイルがコンフリクトを起こしている場合にのみ推奨されます。なぜなら、Subversionシステムは差分をローカルファイルにマージしようとするからです。そのプロセスは、設計文書などの他のファイルタイプを破損させる可能性があるため、コンフリクトは最新のソースリビジョンに更新するか、ローカルの変更を元に戻すことで解決するのが最良です。

  Gitを使用する際、Resolve Conflictコマンドは、ファイルをローカルリポジトリフォルダーにコミットすることによってコンフリクト状態を上書きします。その後、ファイルがリモートリポジトリにプッシュされると、他のデザイナーのファイルはOut of Dateとしてマークされ、更新が必要です。しかし、Subversionを使用する場合と同様に、最も安全な方法は、コンフリクトしたファイルを最新のソースリビジョンに更新すること（Gitの用語ではPull）またはローカルの変更を元に戻すことです。

• Revert – このオプションはローカルの変更を失い（元に戻し）、ローカルファイルをその基本の改訂版、ここではRevision 15に戻します。したがって、改訂の競合は解決されますが、リポジトリに新しい改訂版（Revision 16）が存在するため、そのファイルはOut of dateとしてフラグが付けられます。

リビジョンの比較

バージョン管理での価値ある資産は、設計ファイルの履歴リビジョンを比較する能力であり、これはAltium Designerの内蔵の差分コンパレータによって提供され、Storage Managerパネルからアクセスされます。Differencesパネルと併用することで、VCSリビジョン間の論理的またはグラフィカルな比較が可能になり、影響を受けたオブジェクトをインタラクティブに探索できます。回路図とPCBのリビジョンの両方を比較することができます。

► 差分をナビゲートするための詳細情報については、Differencesパネルページを参照してください。

2つの改訂を比較するには、Storage ManagerパネルのVCS Revisionsリストで両方のエントリを選択し（標準のCtrl+クリック方法を使用）、パネルの右クリックコンテキストメニューからCompareコマンドを選択します。

Projectsパネルのドキュメントの右クリックメニューからHistory & Version Control » Compare with Headコマンドを使用して、フォーカスしたドキュメントをVCSリポジトリのそのドキュメントのヘッドリビジョンと比較することもできます。

Storage ManagerパネルのCompareコマンド

両方のファイルのリビジョンは分割画面モードで開かれ、視覚的に比較できます。表示される違いは、オプションで選択された物理的比較タイプによって決まります。これは、Options for ProjectのComparatorタブのProject » Project Optionsで設定できます。

比較の違いを特定し表示する鍵はDifferencesパネルにあります。このパネルは、文書間の論理的またはグラフィカルな違いの選択可能なリストを提供します。各文書の改訂に対するパネルのリストされた項目はエディターと相互作用し、選択された際に検出された違い（移動したオブジェクトなど）がグラフィカルにハイライトされることを可能にします。

比較の違いを見つけて表示するには、Differencesパネルを使用します。

比較機能は、PCB文書の改訂に加えて、回路図およびテキストベースの文書の改訂にも適用されます。

• 回路図またはPCB（設計またはライブラリ）ドキュメントの場合、グラフィカルな比較が行われ、検出された違いがDifferencesパネルにリストされます。設計エディタウィンドウで2つのバージョンのドキュメントを並べて表示すると、視覚的に違いを確認できます。検出された違いのトップレベルフォルダをクリックすると、両方のドキュメントでその違いが同時に強調表示されます。

• テキストベースのASCIIドキュメントの場合、CompareFormダイアログが表示され、ドキュメントの2つのバージョンのグラフィカルな「差分」が示されます。選択されたドキュメントは横に並べて表示されます。このダイアログは比較用のみで、読み込まれたドキュメントに対する変更は行えません。色分けにより、ダイアログは2つのドキュメントバージョン間のさまざまな違いを強調表示します - 追加された行（ピンク）、変更された行（緑）、削除された行（青）。変更の概要と色分けの凡例がダイアログの下左に表示されます。

比較機能

Compareコマンドは、現在のローカルリビジョン（作業フォルダ内）とリポジトリ内の新しいリビジョンを含む任意のリビジョンペアに適用できます。この状況では、最新のローカルリビジョンはStorage ManagerパネルでOut of date ()として表示されますが、他のユーザーによってリポジトリに追加された新しいリビジョンと比較することはできます。

ローカルのリビジョンは、Storage Managerパネルに「Out of date」と表示されます。

このアプローチにより、新しいリビジョンに更新することによって課せられる変更をグラフィカルにプレビューすることができます。上記の例の画像では、現在のローカルリビジョン（アイコンで示されている）はRevision 19ですが、別のユーザーがリポジトリに新しいリビジョン（Revision 22）をコミットしています。Revision 19とRevision 22の視覚的比較を行うことで、リポジトリからの新しい変更を受け入れるかどうかについて、十分な情報に基づいて判断できます。これにより、Updateコマンドを適用するか、ローカルファイルを再保存して競合を解決することによって、ローカルバージョンを優先させるかを決定できます。

バージョン管理用語

References

• SVNウェブサイト: http://subversion.apache.org/

• SVNオンラインマニュアル: http://svnbook.red-bean.com/

• SharpSVNプロジェクトホーム: https://sharpsvn.open.collab.net

• Gitウェブサイト: https://git-scm.com/

• Gitオンラインドキュメント: https://git-scm.com/doc

• The Tortoise Clients: http://tortoisesvn.net and https://tortoisegit.org/

• Source Control How-to, by Eric Sink: http://www.ericsink.com/scm/source_control.html