retro commits?

Old RCS's "ci" command provides a nice option 

	-d[date]
		Uses date for check-in date and time.  If date is not
		specified, use the working file's last modification time.

It is usually used when someone just forgot a commit and months later on,
someone else does a belated checkin on behalf of the original sinner with
the original date of the deed before continuing with new modifications.


"Why," I hear you asking, "why is he telling us about RCS on a
CVS mailing list/newsgroup?"

It's, uhhh...., disclosure time: Due to a disk failure and backup
negligence I lost a project repository (yes: suits me right), and I
could use exactly this feature.

The main work on the project happened between 1996 and 2001 and I
*do* have a copy of the repository from late 2002 from another disk.
The original cvs server from that time was version 1.11.x, the repository
is now back in place under control of a bleeding egde 1.12.13.1 server.

In the last eight years, I made just about a dozen of really small
changes, mostly for additional Unix platform support.  In fact, I have
checked out the project on about ten different Unix boxen, and am thusly
able to compile a pretty exact history of events.  (Applying all
caveats such as getting the reverse meaning of "needs a patch" in
"cvs stat" output and getting by with "cvs upd -p" to retrieve old
versions without trashing the newer working files.)

Now I want to bring the repository up-to-date by re-doing my commits.
No problem in that, but if possible I'd like to do that with the
original commit dates, too.  Like RCS's "ci -d" would do.

My current plan would be to do a normal "cvs ci" for each change set,
each followed by manually editing the "date" line in the ,v repository
file.  Is that OK?  Has someone else already gone through the required
motions?

							Martin Neitzel