[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Mon, 29 Jul 2002 20:58:25 -0700 (PDT)
On Mon, 29 Jul 2002, Mike Ayers wrote:
> Date: Mon, 29 Jul 2002 15:33:54 -0700
> From: Mike Ayers <address@hidden>
> To: address@hidden
> Subject: [info-cvs] [Fwd: Re: Repairing repository]
> Matt Riechers wrote:
> > address@hidden wrote:
> >>Will update then mark all files which
> >>are different from the repository as commitable, so I can just commit
> >>them and be back where I was? If so, my day just got considerably
> > Essentially, yes. It will be as if you had checked out a fresh
> tree, and
> > just updated those files by hand.
> Unfortunately, this does not appear to be the case. I copy the archive
> from backup to disk, then copy the current development tree from
> backup to its place. When I run `cvs update`, the files in the
> current tree are clobbered to match the repository. Not what I want.
> Am I getting something wrong here?
What you should do is make a fresh checkout, and then copy the
working files over top of that checkout. Then commit.
You will have to hunt down any adds and removes manually.
~$ mkdir fix
~/fix$ cd fix
~/fix$ cvs co project
~/fix$ cp -R ~/good/project . # base names must match!
~/fix$ cd project
~/fix/project$ cvs ci # after checking for adds, etc.
If you use the stale checkout, the problem is that it has CVS/Entries
which have revisions that don't exist in the repository. E.g.
some local file foo.c may be listed as being based on revision 1.10,
but the backup restores only up to revision 1.9. This is really fubar.
I should gloat that Meta-CVS would rock in this situation, because it
has a ``grab'' command that is similar in spirit to CVS vendor imports,
but takes a snapshot to any branch you want, or the trunk.
I would just change to the root of the good sandbox, delete the MCVS
subdirectory, and execute a mcvs grab. That would suck in the
files, taking care of adds removes, and renames.
Meta-CVS: solid version control tool with directory structure versioning.