当上游是 100% CVS 时，去 GIT 的最佳实践是什么？答案

【问题标题】：What's the best practice of going GIT when upstream is 100% CVS?当上游是 100% CVS 时，去 GIT 的最佳实践是什么？
【发布时间】：2016-10-01 19:24:31
【问题描述】：

我很好奇在 git 中（例如，在 github/bitbucket/gitlab 上）保留您对 OSS 项目的偶尔贡献的最佳做法是什么，而上游完全是 CVS。

My take 是非常方便，只需将CVS/{Entries,Repository,Root} 直接提交到git，然后在任何时间从任何框，您都可以简单地签出您的git repo（w/git），然后使用cvs up 从真正的上游更新，这正是我使用my OpenBSD ports-readmes fork 和mdocml 所做的。

但是，我注意到大多数人在我的 GitHub 上的这些 git 存储库中看到这些 CVS 文件时感到非常惊讶和困惑，他们认为这是我的某种疏忽。此外，例如，reyk's httpd 也没有这样的设置，即使他显然通常从上游批量更新它，也不保留来自上游的日志。

我在这里遗漏了什么吗？我觉得在您的 git 存储库中拥有 CVS/{Entries,Repository,Root} 是个好主意，但我从未见过其他人这样做。为什么？

【问题讨论】：

提交 CVS 元数据的一个相当大的问题是它特定于您和您的结帐版本。我这样做的方法是将CVS 添加到.gitignore。这样我仍然可以同时使用 git 和 cvs，而世界其他地方只使用 git，不知道涉及到 cvs 存储库。
@BurhanAli，不，这就是 cvs 的重点——CVS 元数据不是我独有的，而是我的结帐版本特有的，这是重点，因为它完全相同提交给 git 的版本。我看不出将整个CVS/ 添加到.gitignore 有任何好处，因为当您清理本地 git checkout 的那一刻，CVS 数据将不可挽回地消失。这对任何人来说更好吗？如果你不相信我，试试github.com/cnst/mdocml，它应该可以在任何现代系统上与 git 和 cvs 一样工作（先用 git 签出后）。
也许这是当时如何使用 cvs 的人工制品。我使用了extssh 方法，所以我的Root 文件包含类似username@hostname:/repopath 的东西，这对其他人没有用处。我也没有删除该目录，因为我一直在积极地处理它。只需仔细考虑这些文件是否对其他人有用，以及它们的存在是否会引起混淆。
@BurhanAli，即使您的CVS/Root 必须包含用户名，上传CVS/{Repository,Entries} 仍然可以快速设置Root（在文件中或通过@ 的参数987654341@，或通过env CVSROOT），另一方面，如果Entries 文件丢失，在上游找到下游所基于的确切点将非常重要。

标签： git cvs git-pull git-log git-cvs

【解决方案1】：

我觉得在你的 git 存储库中包含 CVS/{Entries,Repository,Root} 是个好主意，但我从未见过其他人这样做。为什么？

这似乎是个好主意，但它也会将元数据（CVS 参考）与数据（您的 repo 文件）混为一谈。

这就是为什么git-svn，例如，在 git 配置中记住相同类型的引用（本地配置文件，不是 repo 的一部分）。
任何想要为上游 SVN 仓库做出贡献的人都需要再次发送 git svn clone。

中间的解决方案是在README 中解释说，如果用户希望回馈给上游 (CVS)，则用户需要在克隆存储库后创建这些 CVS 参考文件。

【讨论】：

问题是 -- git-cvs 集成已经生锈了，因此，将旧式元数据与数据混合似乎是最好的方法。你甚至会如何在自述文件中解释如何生成那些CVS 文件？这非常重要，因为它们必须引用您的存储库应该包含的确切版本。
@cnst 我同意，我只是想找一个中间位置，不建议使用 git-cvs。我使用 git-svn 来说明为什么这种文件通常 not 在 git repo 中。
但我认为您建议的中间解决方案实际上比任何替代方案都差。如果它本身不可行，为什么还要建议它作为一种可能性？
@cnst 因为通常情况下，这一切都是由 git-svn 管理的。如果你没有 git-svn，你必须以某种方式解释你想要做什么（即，用你的方法，解释为什么那些 CVS 文件在那里）
我想你误解了我上面的评论——特别是关于你对 README 的建议以“创建那些 CVS 参考文件”，这似乎是不可能的