Re: change date of a commit

[Eric Siegerman]

On Fri, Jun 29, 2001 at 09:52:30AM +1000, Matthew Herrmann wrote:
> [...] one of the
> computers had the date wrong by 2 months when something was committed so
> there's now some entries for 26 August instead of 26 June. Since the dates
> are to be used for an automatic versioning system, this is going to be a
> thorn in my side. Is there some way I can do this safely? If not, is there
> some dodgy way I can do it?

One way that's kind of in between would be to use "cvs admin -o"
to delete the offending revisions, then recommit them, but it'll
be a pain to get it right, and it'll only work if the bum
revision is the latest one on its branch.  I call this "in
between" because it's not as evil as modifying the ,v files
directly, but any time you delete a revision, you're violating
the spirit of revision control.  (In fact you *could* do this to
multiple revisions per file, but that'd be so much harder and
more error-prone that I'd put it firmly over the line into
"dodgy" territory.)

A much better idea would be to use "cvs ci -f" to check in a new
revision after the offending one (-f forces CVS to create a
revision even if the file's contents haven't changed).  Then add
a kludge to your VB script to "fix" out-of-sequence timestamps
that happen to be for 26-Aug-2001.

> One approach I have considered is search/replace in multi-document editor
> for 2001.08.27 etc. but I'm worried about caning something else in the
> process.

This makes me shudder!  It might not prevent me from doing it in
an emergency, but I'd be cringing the whole time.  I'd probably
do something like:
  - Lock the repo (e.g. bring the server down to single-user, or
    just rename the repo directory and let peoples' attempts to
    access it fail miserably)
  - Make a copy of it
  - Do your substitutions
  - "diff -r backup repo" to make sure you only changed what you
    intended to change.  Use GNU diff; I swear by it (for
    technical reasons, not political ones).
  - Do any other testing you can think of
  - Only unlock the repo when you're *completely* satisfied, no
    matter how loudly users squawk in the meantime

One thing I'm not sure of (which may rule out this whole idea) is
what tweaking a revision's date will do to a sandbox that happens
to have that revision as BASE.  Especially, make sure no sequence
of operations can lead to someone's changes getting clobbered
(i.e. to a commit's up-to-date check succeeding when it should
have failed).  Do some experiments first on a small test repo.

> Needless to say I'm moving soon to a client/server model to avoid
> this and similar issues.

Good plan :-)

> btw, the utility i need this for is a small vb thing which parses the output
> from cvs log into [a condensed version]:
> [...] if this already existed and I reinvented the wheel please let
> me know so I can use that instead

There's rcs2log (in CVS's contrib directory), but it's a shell
script.  Feel like playing with Cygwin? :-)

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
        - RFC 1925 (quoting an unnamed source)