Subject: Re: CVS REPOSITORY IS BROKEN (Re: cvs checkout with tag)
To: Perry E. Metzger <perry@wasabisystems.com>
From: Alan Barrett <apb@cequrux.com>
List: current-users
Date: 01/29/2002 18:23:22
On Tue, 29 Jan 2002, Perry E. Metzger wrote:
> I am sorry, Fukaumi-san. I still do not understand. :(

Let me try to explain, since I think that I know what FUKAUMI Naoki
wants to do, and I am a native English speaker.

We want to check out a complete copy of (some subset of) the tree as
of some date in the past.  We do not know any cvs commands that will
reliably do that while paying strict attention to which files existed
or did not exist on the trunk on particular dates.

We know that the all files under basesrc/usr.sbin/sendmail/* were deleted
from the trunk on 2000-02-13.

If we try "cvs checkout -A basesrc/usr.sbin/sendmail" then it
(correctly) checks out no files.

If we try "cvs checkout -D 2000-02-12 basesrc/usr.sbin/sendmail" then it
(correctly) checks out a whole bunch of old files as they were on that
date.

If we try "cvs checkout -D 2000-02-14 basesrc/usr.sbin/sendmail" then it
decides (as expected) that most of the old files have been deleted, and
does not check them out.  However, it also decides (unexpectedly) to
check out the following subset of the old files:

	basesrc/usr.sbin/sendmail/cf/ostype/bsdi1.0.m4
	basesrc/usr.sbin/sendmail/cf/ostype/dgux.m4
	basesrc/usr.sbin/sendmail/cf/ostype/domainos.m4
	basesrc/usr.sbin/sendmail/cf/ostype/dynix3.2.m4
	basesrc/usr.sbin/sendmail/cf/ostype/sco3.2.m4
	basesrc/usr.sbin/sendmail/makemap/Makefile.dist
	basesrc/usr.sbin/sendmail/praliases/Makefile.dist
	basesrc/usr.sbin/sendmail/src/Makefile.DGUX
	basesrc/usr.sbin/sendmail/src/Makefile.Dynix
	basesrc/usr.sbin/sendmail/src/Makefile.FreeBSD
	basesrc/usr.sbin/sendmail/src/Makefile.Mach386
	basesrc/usr.sbin/sendmail/src/Makefile.RISCos
	basesrc/usr.sbin/sendmail/src/Makefile.SCO
	basesrc/usr.sbin/sendmail/src/Makefile.SVR4
	basesrc/usr.sbin/sendmail/src/Makefile.Titan

There's something funny about these particular files that makes "cvs
checkout -D <some date after the files were deleted>" decide to check
the files out anyway.  I think the fact that the latest main line
revision has "state: Exp" instead of "state: dead" is triggering the
confusing behaviour in cvs.  But the fast that the revisions are not
marked dead does not itself appear to be a bug in cvs, because these
revisions are the base points for branches.

--apb (Alan Barrett)