0

为了对发布给我们客户的所有 jar 文件的内容进行版本控制,在过去几年中,我们一直在这些 jar 中发布一个文本文件,该文件将保存File <-> CVS Version该 jar 中包含的每个 java 文件的映射。CVS 存储库被用作我们的 VCS。

不怀疑当时是否没有更好的解决方案,几个月前,我们决定迁移到 SVN,我们的解决方案是为一个可能随时从客户生产环境中检索到的长期被遗忘的 jar 保留历史,是svn property为每个迁移的 java 文件添加自定义。


例如:

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 签入到那个文件时,比如说 as svn-rev.5700,所有需要做的就是清除该属性。

任务完成——我们本可以完全放弃 CVS。


转移到 Git。

我们路径上的下一步是将一些遗留的 TFS 存储库与我们现在拥有的 SVN 存储库合并,并且不详细介绍,我们希望遵循的方法是将这两者直接迁移到 Git。

我们关心的一个主要问题是如何不丢失在我们第一次迁移期间引入的 svn:cvs 属性。意识到gitattributes似乎是正确的方法,但没有更好的选择吗?真的有必要.gitattributes在源代码周围存储文件吗?(全局文件可能不实用)。此外,从 svn 属性生成这些文件及其历史记录听起来不像是一个简单的脚本。

任何提示将不胜感激。

4

1 回答 1

1

你应该看一下git-notes看看它是否是你想要使用的东西。通常注释附加到提交,但它们可以附加到任何对象,包括文件对象。

将注释附加到文件对象的问题在于,每当该文件更改时,对象也会更改,并且不会复制其注释。但是,您也可以使用一个挂钩,在文件更改时自动更新这些注释。

于 2012-10-02T22:43:37.310 回答