Alternately, if the number of files is reasonably small, you can: - check out _only_ the erroneously committed files to a sandbox (one at a time by rcs version #). - tag them as 'BAD' - check out the last known good versions of these files - tag these as 'GOOD' - Create a new sandbox 'cvs co -jBAD -jGOOD [-rsomeRev/branch (optional)] filea fileb filec fileetc' - Resolve conflicts.... ugh. <-- this is the crappy part. Maybe a task for the naughty dev who did the commit. - commit
This is pretty much the only way to do this if you have committed revs after BAD as the 'cvs up -p foo > foo' method above will _overwrite_ the file and thus all changes made after GOOD rev will be lost. ** Note: this has been lightly tested only. --Russ On Wed, 16 Mar 2005 09:32:37 -0800, Matt Doar <[EMAIL PROTECTED]> wrote: > > > -----Original Message----- > > On Behalf Of Justin > > 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? > > > > Yes, there is. The basic way is to use cvs log to find the version of > the file (foo) before the erroneous commit (1.n), then check it out over > the local copy with: > > cvs update -p -r 1.n foo > foo > > and then cvs diff and commit as usual. There is a more elegant way of > doing it with update -j too. The difficulty comes when the commit was > over dozens of files. Then you need to find the version number for each > file that was affected. I do this using cvs2cl.pl to generate a > changelog and then munge the output into rollback scripts that any user > can run. The changelog will tell you which files all changed together, > and the commit comment should identify the change. > > > 2. I have two versions of our source code I want to import > > into cvs. I > > would like to import the first version, then tag it and import the > > second. But I don't want to tag the second because it's not > > ready yet. > > How can I import the new code into the same trunk as the > > tagged version? > > Import the second as a different tag, then delete that tag? > > After all, > > Import will sync with the trunk, as well as create the tag right? > > > > Thanks for helping out a newbie. > > _______________________________________________ > > Info-cvs mailing list > > [email protected] > > http://lists.gnu.org/mailman/listinfo/info-cvs > > > > _______________________________________________ > Info-cvs mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/info-cvs > _______________________________________________ Info-cvs mailing list [email protected] http://lists.gnu.org/mailman/listinfo/info-cvs
