Glynn Clements glynn.clements at virgin.net
Mon Aug 13 20:10:07 EDT 2001

Glynn Clements wrote:

> These files are still there, and src/display/d.rgb/CVS/Tag contains:
> 	Treleasebranch_11_april_2001_5_0_0
> However, the most recent update adds the old version of d.rgb in
> src/display/d.rgb/cmd, with src/display/d.rgb/cmd/CVS/Tag containing:
> 	Nreleasebranch_11_april_2001_5_0_0
> Note: "T" indicates a branch tag, "N" indicates a non-branch tag.
> AFAICT, any other files which had been removed from the release branch
> have re-appeared in the latest version.

I've just done a "cvs update" (having first backed-up my working
directory) and examined the result. For all of the directories which
have recently reappeared, CVS/Tag contains
Nreleasebranch_11_april_2001_5_0_0, except those which have
subdirectories, for which CVS/Tag contains

AFAICT, this is consistent with someone adding a non-branch
releasebranch_11_april_2001_5_0_0 tag to all of the files at the head. 
Now, clearly CVS shouldn't have allowed this to happen, but it did,
and I'm doubtful that it can actually be undone without restoring from
a backup (which is problematic because people have been continuing to
commit changes).

However, I'm currently executing

	cvs tag -b releasebranch_14_august_2001_5_0_0

on what I think is a correct copy of the release branch, i.e. the one
I had before the problem occurred, with the subsequent commits (listed
in the ChangeLog) added.

If this works, people should be able to get a working copy of the
release branch with:

	cvs update -r releasebranch_14_august_2001_5_0_0

Glynn Clements <glynn.clements at virgin.net>

More information about the grass-dev mailing list