Re: How to commit preserving dates?

[Eric Siegerman]

On Mon, Jan 07, 2002 at 07:52:01PM +0100, J|rgen Backelin wrote:
> For several reasons, I would like to restore old dates of file
> versions committed by means of the cvs ci command.

For being able to recover the state of the project as of a
certain milestone, tags are *much* better than dates.

That said, I too sometimes want to be able to backdate a commit,
not for recoverability (for that, I'd use a tag), but just for
historical purposes, to accurately reflect when the change was
actually made.

Suppose I change a file, want to test the changes for a couple of
days before I commit, and then (scatterbrain that I am -- that's
why I can't work without CVS :-) I forget to do the commit.
Months later, I want to change the file again.  Before I proceed,
I need to commit the previous round of changes.  I'd like to be
able to label that commit with the date (now months in the past)
that the old changes were made, not with the current date when
I'm about to make the next round.

> I guess there might be some way to achieve this with cvs admin;
> but will that mean essentially reverting to old rcs handling
> (with no history logging, et cetera)?

Nope, sorry.

> There ought not to be very hard to make a -d option working for
> cvs ci, like for rcs.

I did this in the ancient past (like maybe CVS 1.7), but my
patches stopped applying cleanly at one point and I never got
around to porting them.  They never worked client/server either.


If you try this approach, a warning:  as you probably know, RCS
doesn't like it if you try to commit a revision with an earlier
date than the predecessor revision (e.g. either rev. 1.4 or
1.3.x.1 with an earlier date than 1.3).  Since CVS uses the RCS
code internally, it inherits the same restriction, and this can
get you into trouble.

Imagine that you try to back-date a whole-directory commit, and
twenty of the files have ancestor revisions with dates later than
the one you gave on the command line.  (Trust me, this *will*
occur in practice.  It happened to me often enough.) The rest of
the files will get committed, but those twenty will not, and
you'll have to clean up the mess.  You'll likely do so by picking
a date "just late enough" for each of those files, or punting and
using the current date (i.e. no "-d") on the second commit.  The
first approach is a lot of work for more than a couple of files;
the second loses the whole advantage of backdating the commit in
the first place (and is especially confusing since some of the
files were backdated and others weren't).

I don't know whether the monotone-increasing-dates restriction is
fundamental to RCS's design, or was added merely to keep people
from doing things that were deemed "unreasonable".  It would
presumably be possible to make RCS stop checking ... but I was
never brave enough to try; I didn't know what might break.

> The only dis-advantage that I see, is that this might open the
> way to potential merging and history related problems, since
> sccs, rcs, and cvs import achieve the restored file date by
> manipulating the record of the time of the commitment.

I can't speak to this; I've rarely had occasion to look at the
history data.

> In my opinion, ideally there should be separate entries for the
> commitment time and the file date; the commitment time should
> be impossible or hard to manipulate (either by cvs import
> or cvs ci); by default, the file 'last changed date' (restored
> at co and export) should coincide with the commitment date, but
> it should be easy to manipulate (both by
> ci and by import).

Interesting idea; I like it, by analogy with UNIX's mtime and
ctime timestamps.  But it would indeed require extensions to the
file format, so I don't think it's likely to happen any time soon
-- even minor proposed changes semiregularly launch flamewars
here.

Good luck.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
One ring to rule the mall.
        - Movie review headline, eye Magazine