回路図とソースコードのバージョン管理

私は、ハードウェア（Eagle回路図）とファームウェア（C ++ソースコード）の2つの部分を持つ電子デバイスを開発しています。ソースコードと回路図の両方の変更を追跡したいのですが、作業を整理する方法がわからない点がいくつかあります。

ソースコードには、間違いなくGitを使用します。しかし、実際にバイナリファイルである場合、回路図はバージョン管理する価値があります（新しいイーグルバージョンはいくつかのXML形式を使用しますが、人間が読むことはできません...）？
ソースと回路図を1つのGitリポジトリに配置することをお勧めしますか？それは理にかなっていますが、一方で私のログにはソフトウェアとハードウェアの両方の変更が含まれます。また、ソフトウェアには複数のブランチを含めることができますが、おそらくハードウェアにはありません...
ハードウェアリビジョンの対処方法それらにタグを付けるか、別々のディレクトリに保存しますか？
また、ハードウェアリビジョンとファームウェアバージョンの間にいくつかの依存関係がある可能性があります。それらに対処する方法？

ベストプラクティスを教えてください。

eagle hardware c++

— クラシク
ソース

商用ソリューションは機能しますか？

— ユージンSh。

私は商用バージョン管理システムに二度と触れません。それらの私の経験は、svnやgitよりもはるかに使いにくいひどいワークフローです。

— pjc50

使用するバージョン管理ソフトウェアが何であれ、回路図を扱うときはテキスト全体を見ないでファイル全体を置き換えていることを確認してください。過去にそれが問題でした。ほとんどの回路図ファイルでdiffを行いたくないでしょう。

— 電圧スパイク

回答:

その大部分は個人的な好みによるものです。

Gitのプロジェクトで行ったすべてを追跡します。特に、Gitはほとんどの種類のファイル（バイナリを含む）を十分に効率的に処理するためです。（組み込みのAltium SVNナンセンスの代わりに）

その主な理由の1つは、Dropboxが十分に安全であると顧客が感じていないことと、世界中でアクセスできるバックアップシステムが必要なことです。そこで、プライベートGitサーバーと暗号化されたバックアップシステムをセットアップしました。ボード、回路図、コード、ドキュメント、レポート、手動修正、すべてが追跡されます。

通常、ハードウェア用のリポジトリ、ソフトウェア用のリポジトリ、ファームウェア用のリポジトリを作成しますが、大規模で長時間実行される可能性のあるプロジェクトの場合は、小規模なサービスプロジェクト、例、または小さな実験の場合、すべてを1つのリポジトリに配置することがよくあります。カオスは大きくなりません。

Gitでは、サブリポジトリを使用して、ファームウェアをハードウェアプロジェクトに統合したり、個別に管理されているリポジトリであっても、その逆を行うことができます。

大規模なプロジェクトでは、バグ追跡システムを使用して問題と解決策を追跡することもよくあります。これもハードウェアとソフトウェアの場合、Mantisは無料で使用できる便利なツールです。

ハードウェアリビジョンの場合、Gerbers、またはそのリビジョンのGitハッシュでタグ付けされたものは何でも、それらのGerbersは、R01、02などによってフォルダー内の唯一の個別の「古い」バージョン管理されたものです。常にそれらを再生成しますが、結果ファイルであるため、Git自体でバージョン管理しないでください（実際、設計ソフトウェアは、プロダクションコンテンツの生成に関して決定的である必要があるため、または...）。

R02で起きていない（またはその逆）R01で興味深いことがある場合、ソースファイルを比較できる2つのGitハッシュがあり、心配はありません。

最後に、プロジェクトの概念的な例の1つに、「BoardPinout.h」ファイルをホストするハードウェアリポジトリがあります。このファイルは、リモートでバージョン管理されたファイルとしてファームウェアリポジトリに含まれています。ファームウェアリポジトリには、ソフトウェアリポジトリにリモートで含まれるいくつかのインターフェイス定義ファイルがあります。

広範な機能を変更せずにいくつかの信号を変更するたびに、HWプロジェクトはBoardPinoutを「更新」し、ファームウェアなどで更新および使用できるようになります。

— アスミルドフ
ソース

それは本当にない今までに異なるリポジトリ内のハードウェアとファームウェアを置くために意味をなさない？それらを1つに持つことはどのように問題になりますか？一緒に属するコンポーネントの変更を追跡する必要がある場合は、むしろ問題になると思います（たとえば、スワップされたIOピンは異なるファームウェア割り当てに反映される必要があり、互換性のないバージョンをチェックアウトすると混乱が生じます）。

— 左辺約

@leftaroundaboutまず最初に、複雑なCAD設計の大部分で急速に変化するFWリポジトリを膨らませるのが常に望んでいるわけではありませんが、サブリポジトリとそれらの間のリンクについても少し読み直したいと思うかもしれません。Gitを使用するのはまったく難しくありません。これは、設計領域間であらゆる種類の不適切な親密さを引き起こすことなく、まさにその問題を修正します。

— アスミルドフ

「私の顧客は、Dropboxが十分に安全だとは感じていません」ファイルのバージョン管理については、100％正しいです。複数のユーザーが同時にファイルを変更できる場合は特に危険です。実際に単一のリソースを構成するファイルが複数ある場合はさらに危険です。バイナリの「ファイルのセット」がこの方法で破損するのを見てきました（興味がある場合は、ESRIファイルジオデータベース）。

— jpmc26

@ jpmc26それは急いだコメントでしたが、バージョン管理はすべて安全性の観点から始められました。いくつかの賢いGitIgnoreテンプレートのバージョン管理により、面倒なことなくすべてが簡単に包み込まれ、すべての利点がもたらされます。実際、共有Dropboxについては完全に同意します。ある顧客サイトでは、無限の問題が発生します。開発中のファイルは、devが最も厄介なものの1つである間、コンピューター上で無限に競合するコピーを生成しなくなりました。

— アスミルドフ

@leftaroundabout：ハードウェアとファームウェアの関係に依存します。通常のソフトウェアプロジェクトとのアナロジーを見てみましょう。あなたのウェブサイトとともにgifおよびjpgファイルをコミットしますか？この場合、画像がそれほど頻繁に変更されなくても、バイナリとソースの両方が互いに変更されます。しかし..プロジェクトでApacheまたはNginxのソースコードをコミットしますか。その点については、Linuxカーネルのソースコードをコミットしますか？この場合、ApacheやnginxのではとLinuxカーネルは、ハードウェアに、より類似している-彼らは変更なく、独立したコードから、あなたは彼らにその実行を書く

— slebetman

1）回路図/ボードファイルをバージョン管理することは間違いなく価値があります。違いをそれほど簡単に追跡できない場合でも、古いデバイスリビジョンで作業する必要がある場合は、特定のハードウェアリリースに戻す簡単な方法があります。

2）SVNには次の構造があります。
/ tag
/ branch
/ trunk / hardware
/ trunk / software / firmware

ソフトウェアの場合は/ Firmwareおよび/ ConfigTool、ハードウェアの場合は/ mainboardおよび/ daughterboardなどのサブフォルダーを使用します。

2）タグは、Tag / Mainboard-v1.2.345のように、トランク全体ではなくサブフォルダーから作成されます。ハードウェア（つまりPCB）には、直接参照できるように、シルクスクリーン印刷または銅のSVNリビジョンが常に含まれています。

4）ハードウェアとファームウェア間の依存関係は複雑になる場合があります。IMOでは、コミットに関する有用なコメントを残すことを除き、リポジトリレベルで対処することはあまり意味がありません。
予備のI / Oピンを使用してハードウェアの変更をエンコードすることを検討してください。4つのピンを使用して16の異なるハードウェアバージョンをエンコードするようなものです。また、異なる抵抗値を持つ単一のADC入力を使用してバージョンをエンコードしました。このようにして、ソフトウェアは実行するハードウェアを「認識」し、特定の機能を変更/無効化/有効化できます。

— Rev1.0
ソース

同意する。実稼働環境へのリリースのたびに、回路図、BOM、ガーバーなど、「リリースバンドル」を構築することもお勧めします。これらをA、B、Cなどと呼び、チームが参照できる場所にアーカイブします。また、どのプロトタイプボードでどのワイヤMODを実行したかを追跡する手段を忘れないでください。

— pjc50

@ pjc50：実際には、「ビルド」リリースバンドルも行いますが、ソース管理はしません（ただし、リビジョンリファレンスを使用）。本質的には、メーカーが入手したすべてのものの正確なコピーになります。大量生産で専門的にハードウェア開発を行う場合、何か問題が発生した場合に備えてすべての情報をすぐに利用できるようにすることが非常に重要です。カスタムPCBの銅の厚さを指定している可能性のある「この1つの重要なドキュメント」というボードハウスを送信したかどうか覚えていない場合、問題が発生する可能性があります。

— Rev1.0