在CVS中的RCS文件格式中，x.y.0.2作为修订说明了什么？

Question

背景

我试图从CVS回购中抢救代码。为了达到这个目的，我使用了reposurgeon，并且我尝试了以下工具来获得git-fast-import流：

• 错误的cvs-fast-export (所谓的循环分支，但没有提供详细信息)
• cvs2git之后是git-fast-export，它将无法理解的东西混在一起
• git-cvsimport紧随其后的是git-fast-export，这创造了迄今为止最好的结果，但最终也会在不属于它们的分支上抛出一些东西。

这个CVS回购已经在各种CVS版本上运行，标签和分支已经被强制移动。我知道这意味着我不能再挽救那些分支和标签了。但就这样吧。

尽管如此，我还是有六个分支(在更多的分支中)，加上MAIN，在转换为git-fast-import流时，我有兴趣保留它。我的目标VCS是而不是 Git，但重点是reposurgeon以这种方式处理它的输入并以这种方式输出。

为了理解工件，并在预处理阶段(当然是在我的回购版的副本上)清除大量的旧东西(包括孤儿版本)，我需要了解rcsfile格式的内部是如何工作的。

在从rcsfile.py修改rcsgrep模块之后，解析是小菜一碟。但这还没有为我提供任何关于修订数字的信息，特别是那些没有相应的delta+log的数字。

我所看到的

根据RCS文件手册页面，不应该出现修订ID的第三段为0的情况。但我看到的正是这种情况。

这是我所做的(作为一个实验)。

1. 在MAIN：提交一个文件(1.1)
2. 从MAIN：分支到BranchX (1.1)
3. 在BranchX上:更改文件(1.1.2.1)
4. 在BranchX上:再次更改文件(1.1.2.2)
5. 在MAIN上:更改文件(1.2)
6. 在MAIN：标记文件foobar (1.2)
7. 从MAIN：分支到BranchX，移动分支标记(1.2)，有效地使以前的分支在1.1.2.x上成为孤儿
8. 关于BranchX：删除文件(1.2.2.1)
9. 在MAIN上:更改文件(1.3)
10. 在MAIN上:强制标记文件foobar (1.3)
11. 在MAIN上:更改文件(1.4)
12. 在MAIN：标记文件foobarbaz (1.4)

正如您在上面的列表和下面完全复制的文件中所看到的那样，不存在带有日志的增量形式的修订1.2.0.2。

现在我的问题

如果我刚退出修订x.y (没有文件更改！)，则得到的修订ID是x.y.0.2。这与我所看到和询问的神秘修订ID相似。

• 0是否表示该文件没有增量，因此我必须返回它的祖先以获取实际内容？
• 还是0仅仅表示该分支的“根”，第四段是该分支的最新修订版？

有人能解释这些问题或指出比上面链接的手册页更全面的材料吗？

下面是完整的RCS文件：

head    1.4;
access;
symbols
    foobarbaz:1.3
    foobar:1.4
    BranchX:1.2.0.2;
locks; strict;
comment @# @;


1.4
date    2014.12.11.13.46.46;    author username;    state Exp;
branches;
next    1.3;

1.3
date    2014.12.11.13.44.49;    author username;    state Exp;
branches;
next    1.2;

1.2
date    2014.12.11.13.39.31;    author username;    state Exp;
branches
    1.2.2.1;
next    1.1;

1.1
date    2014.12.11.13.31.41;    author username;    state Exp;
branches
    1.1.2.1;
next    ;

1.1.2.1
date    2014.12.11.13.34.36;    author username;    state Exp;
branches;
next    1.1.2.2;

1.1.2.2
date    2014.12.11.13.35.08;    author username;    state Exp;
branches;
next    ;

1.2.2.1
date    2014.12.11.13.42.32;    author username;    state dead;
branches;
next    ;


desc
@@


1.4
log
@Change on MAIN
@
text
@NOTE: this file will be removed!

Another change on MAIN@


1.3
log
@Change on MAIN
@
text
@d3 1
a3 1
ANother change on MAIN@


1.2
log
@Change on MAIN
@
text
@d3 1
a3 1
File on MAIN will be forcibly tagged X again ... how does this affect the rev ID?@


1.2.2.1
log
@Removing the two files from X
@
text
@@


1.1
log
@Adding the experiment file
@
text
@d3 1
a3 1
Introducing file on MAIN@


1.1.2.1
log
@Changing the file on the X branch
@
text
@d3 1
a3 1
Changing on X branch@


1.1.2.2
log
@Another change on the X branch
@
text
@d3 1
a3 1
Another change on the X branch@

Answer 1

好的，这个问题的答案就隐藏在CVS源代码的深处。

首先，如果您查看CVS源代码树，下面是重要的文件：

• src/rcs.c
• src/rcs.h
• doc/RCSFILES

除此之外，您还有手册页。不要忘记最大限度地使用grep (除非您有更复杂的东西可供使用，也就是说)。

要旨：

• 分支修正由前三个(或更大的奇数)段定义，即x.y.z，例如1.1.2，它是修订版1.1的分支。
  • 这类分支的符号将指向修订x.y.0.z或1.1.0.2。其中0是在CVS代码中定义为RCS_MAGIC_BRANCH的神奇值。请注意，任何增量都不会将第三段设置为0，因为这些都是“虚拟修订号”。

​

• 在股票CVS z (分支修订的第三部分，虚拟修订数的第四部分)中，只有偶数等于或大于两个。
  • assert((z >= 2) && (z % 2 == 0))

​

• 根据1中的注释，还为供应商分支保留了分支编号rcs.h (参见下文)。
• 要检查分支，只需查看RCS文件的管理部分中的symbols列表(例如，如果您不想解析它，可以通过rlog -h <file> )查看将第二到最后一段设置为0的修订版。也就是说，您有一个与(PCRE)正则表达式(?:\d+\.\d+\.)+0\.\d+相匹配的修订版(希望我做对了)。

来自rcs.h中的评论

CVS保留所有偶数分支供自己使用。“魔术”分支(参见rcs.c)包含在RCS_MAGIC_BRANCH (即0 )之外的虚拟修订号(仅在符号标记中)。CVS还保留".1"分支以供供应商修订。因此，如果您自己做分支，您应该将使用限制为从3开始的奇数分支数。

使用RCS_MAGIC_BRANCH的有趣函数是RCS_tag2rev()和RCS_gettag。

从rcs.c中的评论

对RCS_magicrev()的评论

将“魔术”修订版作为REV文件的虚拟分支返回。一个“魔术”的修订是一个独特的RCS文件。我的意思是，我们返回了一份修订本，其中：

• 有0的一个分支(参见rcs.h RCS_MAGIC_BRANCH)
• 有一个修订组件，它不是REV上的现有分支。
• 有一个修订组件，它不是现有的神奇修订版。
• 是一个偶数的修订，为了避免与供应商分支的冲突，第一点是什么使它“神奇”。

例如，如果我们将1.37作为REV传入，我们将查找一个名为1.37.2的现有分支。如果它不存在，我们将查找一个现有的符号标记，其数值部分等于1.37.0.2。如果不存在这种情况，那么我们就知道可以通过创建一个以1.37.2作为数字部分的符号标记来保留1.37.0.2分支。

..。

注意:我们假设REV是RCS修订，而不是分支编号。

答案

• 0是否表示该文件没有增量，因此我必须返回它的祖先以获取实际内容？
  • 基本上是的。当第二个到最后一个段是0时，修订号是一个虚拟修订号，用于对分支号码进行“预订”。

​

• 还是0仅仅表示了该分支的“根”，第四段是该分支的最新修订版？
  • 不，看上面。

​