为了对发布给我们客户的所有jar文件的内容进行版本控制，过去几年我们一直在这些jar中发布一个文本文件，该文件将保存包含在其中的每个java文件的File <-> CVS Version映射。那罐子CVS存储库正在用作我们的VCS。
当时没有质疑是否没有更好的解决方案，几个月前我们决定迁移到SVN和我们的解决方案，以保留可能在客户生产过程中随时检索的长期遗忘的jar的历史记录环境，正在为每个迁移的java文件添加自定义svn property。
E.g：
My/Foo/Bar.java已将CVS版本1.2.33.5迁移到SVN，因为svn-rev.5678会收到以下属性：svn:cvs = 1.2.33.5。
上次更改为My/Foo/Bar.java（CVS版本1.2.33.4）已映射到svn-rev.5145，其中我们的文件的svn属性设置为svn:cvs = 1.2.33.4。
可以轻松浏览该文件的SVN状态/日志，因此可以同时对该文件进行更改以及svn:cvs属性值的历史记录。
现在，当一个新的svn签到来到该文件时，比如svn-rev.5700，所有需要做的就是清除属性。
任务完成 - 我们可以完全放弃CVS。
转移到Git。
我们的道路上的下一步是将一些传统的TFS存储库与我们现在拥有的SVN存储库合并，而不是详细介绍，我们想要遵循的方法是将这两者直接迁移到Git。
我们遇到的一个主要问题是如何不放弃在第一次迁移期间引入的svn：cvs属性。意识到gitattributes他们似乎是正确的方法，但没有更好的选择吗？是否真的有必要在源代码周围存储.gitattributes个文件？ （全局文件可能不实用）。此外，从svn属性生成这些文件及其历史记录听起来不像是一个简单的脚本。
任何提示都将受到赞赏。