[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Copying/duplicating a repository
From: |
Simon Renshaw |
Subject: |
RE: Copying/duplicating a repository |
Date: |
Thu, 12 Jul 2007 10:52:40 -0400 |
Hi Todd,
This is what I tried, not sure how good it is.
First I created the new repo and initiated it.
We use CVS with Eclipse. So I did a checkout. Then I disconnected and
shared it on the new repo.
Anything wrong if I do that beside losing history?
Thanks!
Simon
-----Original Message-----
From: Todd Denniston [mailto:address@hidden
Sent: 12 juillet, 2007 10:39
To: Simon Renshaw
Cc: cvs
Subject: Re: Copying/duplicating a repository
Simon Renshaw wrote:
> Hi,
>
>
>
> What is the best way to copy a repository?
>
>
>
> I want to make a copy of a production repository so we can do tests
> without affecting the real code.
>
Here is how I would do it:
0) have everyone else stay out of the repository for a little while.
1) make _TWO_ good backups of the repository, and verify they are good.
2) take one of the backups and restore it to a new directory/machine.
3) make sure that nothing in $CVSROOT/CVSROOT of the NEW repo points to
scripts/info files in the OLD repo.
4) make sure if you have other scripts which work with your repo, that
you get
copies of them and appropriately modify.
5) Assuming you are not using pserver, just update your $CVSROOT value
to
point at the new test repo.
6) have everyone else stay out of both repositories for a little while
longer,
a) run some test cvs commands that write to the repo, like `cvs
tag`, and
make sure only the new test repo changes.
b) any of the scripts you use against the repository, and make
sure only the
new test repo changes.
c) decide if you want to run (a) & (b) from a "normal" account
and verify
this time it is the original repo that changes.
d) decide if you need to fix something and how (you might want
to use a
backup to restore the original repo if you did (c) ).
7) let everyone know they can go back to work with the repo.
8) let your nerves settle.
9) make a new good backup of the test repo so, if you break it good, you
don't
have to stop work on the normal one again to restore it to this point.
10) break the testing repo. :)
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter