retro commits?

[Martin Neitzel]

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

[Bob Proulx]

Post by Martin Neitzel
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?

Personally I would probably commit all of the changes without regards
to the date and then edit the ,v files to update the relevant dates.
That seems reasonable since you say you are already planning on
editing those files.

Alternatively I would use libfaketime[1] to set the time and do local
commits. You could script it to stat the file and use that timestamp
as the current time.

Bob

[1] http://www.code-wizards.com/projects/libfaketime/index.html

[Yaron Yogev]

Post by Bob Proulx

Post by Martin Neitzel
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?

Personally I would probably commit all of the changes without regards
to the date and then edit the ,v files to update the relevant dates.
That seems reasonable since you say you are already planning on
editing those files.
Alternatively I would use libfaketime[1] to set the time and do local
commits.  You could script it to stat the file and use that timestamp
as the current time.
Bob
[1]http://www.code-wizards.com/projects/libfaketime/index.html

Hi,

Why not use "RCS ci -d" directly on the repository files in the
server ?

Yaron