AFAIU, the gcc_3_4_0_release tag seems to be misplaced on several files in CVS.
cvs co -r gcc_3_4_0_release
cvs diff -uNR
produces a larger diff containing files that seem to be tagged gcc_3_4_0_release
but not contained in the actual release (As it seems to me these files have been
tagged gcc_3_4_0_release but had been "cvs rm"'ed afterwards).
This causes problems when having local additions in a checked out copy of
gcc-3.4-branch and wanting to generated diffs against gcc-3.4.0
(cvs diff -uNR -r gcc_3_4_0_release)
I'd expect removing the gcc_3_4_0_release tag from these files to fix this issue.
Subject: Re: New: CVS Misplaced gcc_3_4_0_release tags
On Fri, 21 May 2004, ralf_corsepius at rtems dot org wrote:
> produces a larger diff containing files that seem to be tagged gcc_3_4_0_release
> but not contained in the actual release (As it seems to me these files have been
> tagged gcc_3_4_0_release but had been "cvs rm"'ed afterwards).
These look rather like files that were deleted on 3.4 branch before the
release was made. As the revisions have status "dead" (i.e., deleted
files), I fail to see the intrinsic problem; cvs tag does put tags on some
dead revisions; they may not be useful but any problems they cause sound
like bugs in other software.
> This causes problems when having local additions in a checked out copy of
> gcc-3.4-branch and wanting to generated diffs against gcc-3.4.0
> (cvs diff -uNR -r gcc_3_4_0_release)
This sounds like a bug in cvs diff.
(In reply to comment #1)
> These look rather like files that were deleted on 3.4 branch before the
> release was made. As the revisions have status "dead" (i.e., deleted
> files), I fail to see the intrinsic problem;
I don't know what you mean by "intrinsic problem", but the "user side problem"
is "plain simple":
cvs diff -uNR -r gcc_3_4_0_release
produces invalid diffs.
> This sounds like a bug in cvs diff.
May-be, I don't know.
Subject: Re: CVS Misplaced gcc_3_4_0_release tags
On Sat, 22 May 2004, ralf_corsepius at rtems dot org wrote:
> > These look rather like files that were deleted on 3.4 branch before the
> > release was made. As the revisions have status "dead" (i.e., deleted
> > files), I fail to see the intrinsic problem;
> I don't know what you mean by "intrinsic problem", but the "user side problem"
A problem with the contents of 3.4.0 implied by the semantics of the
repository contents not agreeing with the contents of 3.4.0 as released in
tarballs. The format of CVS repositories may not be perfectly documented,
but the manual says:
# A `dead' state means that file has been removed, or
# never added, for that revision.
I.e., dead state on 3.4 branch means the file has been removed or never
added on 3.4 branch, and dead state for 3.4.0 release means the file is
not in 3.4.0 release, and tools treating it as such are in error.
The release script would have built the tarball with cvs export
-rgcc_3_4_0_release, and it does not appear to include the files you list,
and from your bug report, it seems that cvs co is correctly interpreting
the repository as well. If checking out from a tag and immediately
running a diff against that tag shows any diffs, that clearly indicates a
CVS bug in that different commands are interpreting the same repository
differently. In this case, it seems to be cvs diff which is making an
So not a bug in our repostitory but a bug in CVS.