Re: CVS server upgrade?

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Spiro Trikaliotis <address@hidden> writes:

> Hello,
> 
> * 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
> 4.?

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
the repository.

    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 \
          newbox.example.com:/path/to/your/new/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
       purpose.

    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
fairly soon.

        Enjoy!
        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFAH3QF3x41pRYZE/gRAr1/AJ9O4UiJuuUT8X9fqXy1uIrUCyRbWQCfYkiq
VmXvIkOZCyVpaAMgnU3P55I=
=3wCu
-----END PGP SIGNATURE-----