お客様にリリースされたすべてのjarファイルのコンテンツをバージョン管理する目的で、過去数年間File <-> CVS Version、そのjarに含まれる各Javaファイルのマッピングを保持するテキストファイルをそれらのjar内にリリースしてきました。CVSリポジトリはVCSとして使用されていました。
当時、より良い解決策がなかったかどうかは疑問の余地がありませんでした。数か月前に、SVNに移行することを決定し、顧客の本番環境からいつでも取得された可能性のある長い間忘れられていたjarの履歴を保持するための解決策でした。svn property移行された各Javaファイルにカスタムを追加します。
例えば：
My/Foo/Bar.java次のプロパティを受け取るように、CVSバージョン1.2.33.5でSVNに移行されました。svn-rev.5678svn:cvs = 1.2.33.5
My/Foo/Bar.java（CVSバージョン）への最後の変更は、ファイルのsvnプロパティがに設定されている1.2.33.4にマップされました。svn-rev.5145svn:cvs = 1.2.33.4
そのファイルのSVNステータス/ログは簡単に参照できるため、そのファイルに加えられた変更とsvn:cvsプロパティ値の履歴の両方を参照できます。
これで、新しいsvnチェックインがそのファイルに到着したとき、たとえば、のように、実行svn-rev.5700する必要があるのはプロパティをクリアすることだけです。
ミッションは達成されました-CVSを完全に削除できたはずです。
Gitに移行します。
私たちのパスの次のステップは、いくつかのレガシーTFSリポジトリを現在のSVNリポジトリとマージすることです。詳細については説明しませんが、私たちが従うアプローチは、これらの両方をGitに直接移行することです。
私たちが抱えている大きな懸念の1つは、最初の移行中に導入されたsvn：cvsプロパティを失わないようにする方法です。gitattributesを知っていると、正しい方法のように見えるかもしれませんが、これ以上の選択肢はありませんか？.gitattributesソースコードの周りにファイルを保存することは本当に必要ですか？（グローバルファイルはおそらく実用的ではありません）。また、svnプロパティからこれらのファイルとその履歴を生成することは、書くのが簡単なスクリプトのようには聞こえません。
ヒントは大歓迎です。