[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: change date of a commit
From: |
Eric Siegerman |
Subject: |
Re: change date of a commit |
Date: |
Thu, 28 Jun 2001 22:34:10 -0400 |
User-agent: |
Mutt/1.2.5i |
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)