Re: CVSUP fixup messages for CVS-1.11.22. Regression between 1.11.20 and 1.11.21.

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Anton,

Anton Kornev <akornev@gmail.com> writes:

> There is a famous tool for CVS repository syncronization called
> "CVSUP", and we have found it producing a lot of "fixup" messages last
> time. It means it can't parse RCS to send diff and have to transfer
> entire file from server to client.

You could work around this problem in one of a few ways:

  a) Add and then remove a new revision against version 1.1 of the
     RCS ,v files. (Probably using an explicit vendor branch number.)
     This will rewrite all of the files in the repository using the new
     revision of CVS delta ordering.

  b) On the CVSup clients, either perform the same operation on the
     repository. Or, if the mirror has no local changes at all to be
     lost, you could temporarily use the 'norcs' option in the supfile
     to mirror exactly what is on the parent.

or, you might be able to find a way to fix CVSup to do the right thing.

> After some investigation we found it to behave like this after
> commits/ setting tags with CVS
> later than 1.11.20 version.

Okay.

> I took a look into RCS files produced with the latest CVS version and
> I found that for some reason it changing order of "revisions" (I am
> not sure exactly how to explain it) inside RCS file.

The RCS file is a structured file. The deltas had one default order due
to how the revisions were traversed and you are observing that newer
updates of the file has altered this default order.

> F.ex. when I set tag TAG_015 to the file in my repository it sets the
> tag itself in the header
> of my Makefile,v
> 
> BEFORE:
> 
> head    1.15;
> access;
> symbols
>         TAG_012:1.15
>         TAG_011:1.15
>         TAG_010:1.15
>         TAG_009:1.15.0.4
>         TAG_008:1.15
>         TAG_007:1.15
> 
> AFTER:
> 
> head    1.15;
> access;
> symbols
>         TAG_015:1.15
>         TAG_012:1.15
>         TAG_011:1.15
>         TAG_010:1.15
>         TAG_009:1.15.0.4
>         TAG_008:1.15
>         TAG_007:1.15

The above change is more likely due to the removal of the TAG_015 tag
than it is to a change in RCS. If you are able to reproduce the loss of
a tag in an RCS file, then that is indeed a bug and needs to be fixed.
Please provide a test case if possible for this problem.

> But it also do the following:
> 
> 
> BEFORE:
> 
> 1.2
> date    2004.10.15.17.54.17;    author gazik;   state Exp;
> branches;
> next    1.1;
> 
> 1.1
> date    2004.10.12.21.27.34;    author gazik;   state Exp;
> branches
>         1.1.1.1;
> next    ;
> 
> 1.1.1.1
> date    2004.10.12.21.27.34;    author gazik;   state Exp;
> branches;
> next    ;
> 
> 1.7.2.1
> date    2005.11.17.20.08.36;    author dmitri;  state Exp;
> branches;
> next    ;
> 
> 1.12.6.1
> date    2006.06.12.16.34.05;    author gazik;   state Exp;
> branches;
> next    ;
> 
> 
> desc
> 
> AFTER
> 
> 
> 1.2
> date    2004.10.15.17.54.17;    author gazik;   state Exp;
> branches;
> next    1.1;
> 
> 1.1
> date    2004.10.12.21.27.34;    author gazik;   state Exp;
> branches
>         1.1.1.1;
> next    ;
> 
> 1.12.6.1
> date    2006.06.12.16.34.05;    author gazik;   state Exp;
> branches;
> next    ;
> 
> 1.7.2.1
> date    2005.11.17.20.08.36;    author dmitri;  state Exp;
> branches;
> next    ;
> 
> 1.1.1.1
> date    2004.10.12.21.27.34;    author gazik;   state Exp;
> branches;
> next    ;
> 
> 

To the best of my understanding the ordering of the delta header records
is not mandated in the RCS file format. If you find there is indeed such
a specification, then please point to the text in the RCS source
document which specify it.

> desc
> @@
> 
> 
> Please, notice that 1.1.1.1 and 1.12.6.1 changed their places.
> Unfortunately CVSUP goes crazy from this.

This would seem to be a bug in CVSUP. Have you reported it yet?

> With further investigation I found the place it was changed inside CVS
> code

> - it is a RCS_putdtree() function in src/rcs.c source. It was
> completely rewritten from recursive to non-recursive version and it
> seems it was a bit broken during the rewrite.

Please specify why it is broken? The order of the various delta records
in the file is not specificed in the RCS file format standards to the
best of my understanding.

The original implementation of the RCS_putdtree() function was subject
to stack overflow during very large number of revisions. The
non-recursive version is not subjection to those limitations.

See https://savannah.nongnu.org/bugs/?func=detailitem&item_id=14435
for details.

The newly rewritten RCS files are completely self-consistent which is
the primary goal of the CVS maintainers. I suspect that if you
'temporarily' update your supfile to use 'norcs' to disable the
assumptions that CVSup might otherwise be making about ,v files, your
problem will be resolved.

> I took the older RCS_putdtree() function into the latest 1.11.22 and
> now it works fine for me. But it will be nice to have it fixed in
> future releases of CVS.

If you are certain you are not going to use local branches in the mirror
repository, then you could just update your supfile to use the 'norcs'
option.

Note that if your mirror repositories have local changes, you do NOT
want to use the 'norcs' option, which would throw away all of your local
branch changes and tag information.

If you still feel this is an undesirable switch in behavior, please feel
free to rewrite the RCS_putdtree to be non-recursive and still retain
the order you feel is most correct and submit a patch to
bug-cvs@nongnu.org

I do not believe we can afford to revert to the known buggy recursive
method.

        Good luck,
        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)

iD8DBQFGYJLZCg7APGsDnFERAmTiAJ4zIS2656ld0iRHWYh5HTSfyFs9FgCcCgmW
n4WCowou6XKk383xYHQy2AQ=
=/S+7
-----END PGP SIGNATURE-----