[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CVS server upgrade?
Mark D. Baushke
Re: CVS server upgrade?
Tue, 03 Feb 2004 02:12:21 -0800
-----BEGIN PGP SIGNED MESSAGE-----
Spiro Trikaliotis <address@hidden> writes:
> * On Mon, Feb 02, 2004 at 03:00:35PM -0500 Jim.Hyslop wrote:
> > In order to minimize the impact on the users, we took the original server
> > off-line just long enough to create the tarball. As soon as the tar was
> > complete, we restarted the server in read-only mode (create an empty
> > CVSROOT/writers file to make the whole repository read-only). Thus, people
> > could still check out and browse the repository, but they couldn't check
> > anything in (and thus throw the two repositories out of sync).
> not that I would recommend it, but:
> But about
> 1. Taking the CVS repository offline
> 2. Create the tarball
> 3. Take the CVS repository online with full access (!)
> 4. do anything needed to move to the new server
> 5. When everything is working fine, take the (original) repository
> offline again
> 6. Now perform an rsync between the two repositories
> 7. Take the new one online (with changing DNS entries and the like).
> Would this make sense, or could 6. break something that was made with
Sure #6 could break something for #4, this is why it is considered
useful to test our your commitinfo, loginfo, verifinfo, and taginfo
scripts to be sure they wok regardless of the platform.
Your steps should work okay.
> I understand that this procedure seems more "risky", but it seems to me
> that this should work, too, shouldn't it?
I have had occasion to move repositories from one machine to another a
number of times over the years.
I typically put something into the commitinfo script that denies any
commits to the repository unless the `hostname` matches what I expected.
I have also used 'rsync' (or CVSup soemtimes) to create mirror copies of
0. Assume you have two machines oldbox.example.com and
newbox.example.com and that everyone checks out using
cvsbox.example.com which happens to be a DNS CNAME that
points to oldbox.example.com.
1. Mirror the repository to a slave server (newbox) that will become
the master eventually. On oldbox.example.com do the following:
rsync --exclude '#cvs*' --exclude ',*,' --blocking-io \
--recursive --perms --owner --group --times --links \
--delete --stats /path/to/your/current/cvsroot/directory \
doing this rsync a few times in succession, I would expect to
eventually not see any additional files copied. At that point,
you have your functional mirror for testing and/or deployment.
2. test the new repository for the ability to checkout a tree any
commits to this version of the repository will likely fail due to
your commitinfo trigger test for the filename. It is up to you if
you want to allow test commits to this test repository or not. I
typically have a 'debugging' repository and module for this
3. Modify the the commitinfo trigger on the master repository, so
that only commits to the mirror are allowed. This will have the
effect of making the current master repository a read-only mirror
that will not allow commits.
4. Repeat step #1 to effectively make the 'slave server' become
the new master.
5. Alter your DNS so that cvsbox.example.com has a CNAME record
that points to nwebox.example.com instead of oldbox.example.com.
You are now done and should be able to retire the oldbox.example.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
-----END PGP SIGNATURE-----