そのため、ファイルシステム全体に散在するファイルとフォルダーを結び付けるプロジェクトがあります。論理的には、これらのファイルはすべて単一のプロジェクトに属しているため、単一の SVN リポジトリに属していますが、関連するプログラムはすべてソース コードを特定のディレクトリに保存するようにハードコードされているため、それらを単一のフォルダー階層に結合することはできません。
このようなシナリオに対処するのは私が初めてだとは思わないので、簡単な解決策を見落としていることを願っています。4 つのアプローチを検討しましたが、いずれも欠点があります。私が検討していない別のアプローチはありますか、またはそれを禁止していますが、誰かが長期的に最良のアプローチへの洞察を提供できますか?
私が検討したアプローチは次のとおりです。
- 各システム フォルダー内の SVN リポジトリの適切なサブフォルダーをチェックアウトします。おそらく技術的には最も単純ですが、単一の「論理的な」コミットを構成するために多くの個別のコミットが必要になるのは好きではありません。アップデートも同様。
- SVN チェックアウトを 1 つの場所に保持し、プログラムを使用して SVN 階層とシステム フォルダーを同期します。SVN の使用を少し簡単にしますが、可動部分が増えます。誰かが間違った方向に同期した場合、コミットされていない作業を上書きすることも非常に簡単です。
- 単一の SVN チェックアウト、システム フォルダーへのジャンクション/シンボリック リンクを使用します。私の試みといくつかの Web 検索に基づくと、これは現時点では技術的に不可能のようです。少しもろい感じもします。
- 逆に、ハードコードされたプログラム フォルダーを変更して、SVN チェックアウトのサブフォルダーへのシンボリック リンク/ジャンクションにすることができるかもしれません。ソフトウェアの更新によってシンボリックリンクが置き換えられるか、1 つまたは複数のプログラムがシンボリックリンクを好まない可能性があります。
このリポジトリで作業する一部の人々は開発者ではないことに注意してください. また、これは Windows 環境であり、通常は TortoiseSVN を使用することに注意してください。Git/mercurial/etc はオプションではありません。会社のポリシーでは、SVN をリリース プロセスに組み込む必要があります。
「おそらく機能する可能性のある最も簡単なこと」のアプローチに従うと、＃1が進むべき道のようです。しかし、おそらく（うまくいけば？） 私が見逃しているものがありますか？