[GRASS5] WARNING: CVS broken

[Glynn Clements]

Markus Neteler wrote:

> I am trying to understand the "cvs log" command.
> At time I have to analyse a 120000+ lines file (stuff from May to today),
> which is VERY boring. This I have created with
> 
> cvs log -d">2001-05-20" > cvs_log_everything_since_may.txt
> 
> (idea from:)
> http://www.cvshome.org/docs/manual/cvs_16.html#SEC141
> 
> However, I want to see only non-release-branch commits.
> But I don't get the "-r" flag working:
> 
> cvs log  -d">2001-05-20" -r ::releasebranch_11_april_2001_5_0_0
> cvs server: nothing known about ::releasebranch_11_april_2001_5_0_0
> 
> (note, the "::" shall limit the search. From the docs above:
> "::rev 
>                     Revisions from the beginning of the branch up to, but
>                     not including, rev. 
> "
> 
> It seems I am missing something, any CVS experts out there?

Note: "revision" normally implies a non-branch tag.

My CVS documentation doesn't mention "::". I'm currently running
1.10.7; I'll upgrade to the latest version.

> I still try to understand *how* to interplete the cvs log file. As I
> remember Glynn had the problem that d.rgb was added to the wrong
> (non-)branch or whatever. So I focus on this module to understand
> what's going on here.

More precisely, d.rgb/cmd "reappeared" when it acquired the non-branch
version of the tag. d.rgb/cmd shouldn't be in the release branch, but
d.rgb itself should (containing just Gmakefile and main.c).

> So, using:
> 
> cvs log -d">2001-05-20" -r:releasebranch_11_april_2001_5_0_0 -wglynn |grep -v OBJ
> 
> to check for "glynn"'s checkins I have seen that d.rgb lives in the
> "Attic" of CVS (most of other modules not).
> 
> Might the "Attic"-home of a module be an indicator for something has been
> gone wrong?

Probably not; the Info file says:

   ... It should not matter from a user point of view whether a
  file is in the attic; CVS keeps track of this and looks in the attic
  when it needs to.  But in case you want to know, the rule is that the
  RCS file is stored in the attic if and only if the head revision on the
  trunk has state `dead'.  A `dead' state means that file has been
  removed, or never added, for that revision.  For example, if you add a
  file on a branch, it will have a trunk revision in `dead' state, and a
  branch revision in a non-`dead' state.

d.rgb/main.c shouldn't exist at the head of the trunk, only on the
release branch so, according to the above, it should be in the attic. 
The other files (d.rgb/Gmakefile and d.rgb/cmd/*) shouldn't be in the
attic.

> Well, if the non-branch-tag elimination also removed this tag description
> (while keeping the sources) I feel that neither "cvs log" nor "cvs status"
> can see anything (as it is removed). Hopefully I am wrong.

Those commands won't tell you anything about the tag, but the actual
revision history is still there.

In case it's of any help, I'll "dump" a summary explanation of what I
understand regarding CVS tags.

Basically, every file has a revision "tree", with the individual
revisions and branches having numeric versions. Revisions on the trunk
have two-part versions (1.1, 1.2, 1.3, ...). If revisions are then
committed on a particular branch, they will have have versions which
start with the last version on the trunk.

Consider the file src/libes/gmath/Gmakefile as an example. The initial
commit was version 1.1. The first update was committed to the trunk,
and is version 1.2. At that point, a branch (1.2.4) was created (the
first branch, 1.2.2, never received any commits). Subsequent revisions
were committed to the branch, with versions 1.2.4.1, 1.2.4.2, ...,
1.2.4.5. At this point, I created the "august" branch (1.2.4.5.2,
which was a branch of the "april" branch), and committed my changes on
that, as version 1.2.4.5.2.1. Once the problems with the bogus "april"
tag were sorted out, I also committed the changes on the "april"
branch, as version 1.2.4.6 (these two versions are identical).

1.1 --> 1.2
        |
        +--> 1.2.4.1 --> 1.2.4.2 --> 1.2.4.3 --> 1.2.4.4 --> 1.2.4.5 --> 1.2.4.6
                                                             |
                                                             +--> 1.2.4.5.2.1

Symbolic tags serve to identify a "snapshot" of the repository,
identifying which versions of particular files belong together.

Tags are "static"; they are interpreted at the time a "cvs" command is
executed. No historical information is recorded for them. Tags are
converted to the appropriate numeric version for each file as the
command is run. When operating on a single file, you could always just
specify numeric versions instead. Operations on multiple files are
basically equivalent to many single-file operations, with the tag
converted to the appropriate numeric version for each file.

> It is not clear to me *when* (Date) the non-branch tag
> "releasebranch_11_april_2001_5_0_0" has been applied. This may reduce the
> number of log-lines to analyse (at time 250k lines).

I'm fairly sure that the problems all started at some point on
2001-09-09, although it's conceivable that it occurred late on the
8th.

cvs log -d '>2001-09-08 00:00' should catch everything that might have
been lost. Basically, you're looking for 2-part versions (1.x), which
indicate that a commit was made to the trunk.

-- 
Glynn Clements <glynn.clements at virgin.net>