info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: rolling back and importing


From: Todd Denniston
Subject: Re: rolling back and importing
Date: Wed, 16 Mar 2005 09:53:22 -0500

Justin, with a bogus email address, wrote:
> 
> Hi,
> 
> Disclaimer: Unfortunately I come from a Visual Source Safe world, so
> please forgive my stupid questions:
> 
> 1. Recently a developer submitted some bad code to the CVS server. I
> asked my local cvs contact how I could rollback the changes the dev
> made. I was informed that it would be difficult because there wasn't a
> recent tagged version. I found this perplexing, as this is pretty easy
> to do in Source Safe. There must be a way in CVS?
> 
If the checkin action on the repository has a good quantity of time between
the checkins on either side of the "bad code" checkin, you could probably
use the "implicit" tags CVS applies, that is, checkin date+time.

Note that I have not tried this recently so you should probably back up your
repo, and/or try it on a copy of your repo first.

1) cd to the root of a checked out sandbox.
2) run `cvs2cl -r -t` [1] on a checked out sandbox. 
3) find the offending commit in the Changelog file (the output of cvs2cl).
4) find the time of the offending commit (BADTIME), and the commit previous
to it (BEFORBADTIME).
Note 4a: cvs2cl outputs time in "local" and CVS uses UTC.  when doing the
tags below you either need to convert the cvs2cl time to UTC, or tell cvs
that the time given to -D is in your timezone, that is, if you are in TZ=EST
you tell cvs '-D"BADTIME EST"'.
Note 4b: that you may need to _add_ a 'fudge' to the date time of a few
seconds or a minute to get the tags applied to the versions you want. This
is why you want to see some time between the commits.
4a) If there is a good delay before and after the bad commit, you can use
the times, if not you will have to apply the tags to the REVISION of each
_file_ individually (not an easy task, been there done that).
5) run `cvs tag -DBADTIME BrokenCommit` on the whole sandbox.
6) run `cvs tag -DBEFORBADTIME BeforeBrokenCommit` on the whole sandbox.
7) re-run `cvs2cl -r -t` and you should see BrokenCommit and
BeforeBrokenCommit listed as "utags" in each of the commits identified in
step 4, if not you may have to increase the 'fudge'.

You now have the recent tagged versions your cvs contact wanted, perhaps now
you might check with that person to see if my next command is good/bad.

8) run `cvs update -jBrokenCommit -jBeforeBrokenCommit` on the whole
sandbox, Note I almost expect have this command wrong.


[1] http://www.red-bean.com/cvs2cl/

-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter




reply via email to

[Prev in Thread] Current Thread [Next in Thread]