Git 为什么rcs co on，v文件会为某些用户创建0kb的文件？

操作系统和工具信息：我正在使用Cygwin在Windows7上的mintty Unix bash的最新2/11/2015更新

我正在将CVS存储库转换为使用Git，并需要从tarball恢复文件。在提取文件后，我尝试使用cvs签出，这得到了一些文件，但大多数文件都在阁楼目录中，并且没有签出，即使我将它们全部移动到一个目录中，使它们不在阁楼中，正如在这不起作用后建议的那样，我尝试了cvs2svn，但无法解析。最后，我尝试使用常规的RCS co，它创建了我需要的大部分文件

但是，一个顶级目录中阁楼子目录的所有转换文件都是空的0kb。即使将，v文件移动到更高级别，它们也无法正确提取

为以下各项编写rcs协同工作代码

$ pwd
/tmp/test/repo/<working-directories>/
$ find . -type f -wholename "*Attic/**,v" -exec rcs co {} \;
$ find . -type f -name "*,v" -exec rcs co {} \;

$ cd /tmp/test/repo/<trouble-directory>
$ find . -type f -name "*,v" ! -wholename "*Attic/**,v" -exec rcs co {} \;

但是，对于以下命令，rcs不能正常工作，它会创建大小为0kb的文件

$ pwd
/tmp/test/repo/<trouble-directory>
$ find . -type f -wholename "*Attic/**,v" -exec rcs co {} \;

移到顶层不起作用

$ pwd
/tmp/test/repo/<trouble-directory>
$ find . -type f -wholename "*Attic/**,v" -exec mv {} . \;
$ find . -maxdepth 1 -type f -name "*,v" -exec rcs co {} \;

$ pwd
/tmp/test/repo/<trouble-directory>
$ find . -type f -wholename "*Attic/**,v" -exec mv {} ../<working-directory> \;
$ cd /tmp/test/repo/<working-directory>
$ find . -maxdepth 1 -type f -name "*,v" -exec rcs co {} \;

即使移动到工作目录也不起作用

$ pwd
/tmp/test/repo/<trouble-directory>
$ find . -type f -wholename "*Attic/**,v" -exec mv {} . \;
$ find . -maxdepth 1 -type f -name "*,v" -exec rcs co {} \;

$ pwd
/tmp/test/repo/<trouble-directory>
$ find . -type f -wholename "*Attic/**,v" -exec mv {} ../<working-directory> \;
$ cd /tmp/test/repo/<working-directory>
$ find . -maxdepth 1 -type f -name "*,v" -exec rcs co {} \;

---

什么可以解释rcs co的这种行为？其他文件的大小和扩展名相似。在存储库的文档中，我似乎找不到任何东西可以对这个特定目录中的阁楼文件进行任何不同的处理，我也找不到任何配置中的冒烟枪。有什么想法吗？

一些开发人员签入一个大小为零的文件，表示该文件已被删除。或者，他们可能依赖于版本标签，并从该标签中省略了文件

如果是这样做的，rlog将显示更改，并且通常带有一条注释，说明文件已被删除

此外，可以使用rlog显示的tip/head版本编写脚本，以倒计时一个版本并获取文件的最后一个非空版本。当然，这更为复杂，但问题是为什么，而不是如何，一个合适的脚本将是一个单独的答案。

问题是它们被删除或以其他方式不可用。这样一个文件的最新版本可以合理地表示为一个空文件，或者根本没有文件

如果你想从阁楼上取回早期版本，我想你可以；但是，您在项目历史中引入了不一致性

---

我在这方面没有什么经验，但如果我是你的话，我会首先尝试。您并不是第一个想从CVS迁移到Git的人。

再说一遍，每个工具都可能有问题。在寻找git/cvsimport时，我看到了一些相关的。