[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVS server upgrade?

From: Mark D. Baushke
Subject: Re: CVS server upgrade?
Date: Tue, 03 Feb 2004 02:12:21 -0800

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 and and that everyone checks out using which happens to be a DNS CNAME that
       points to

    1. Mirror the repository to a slave server (newbox) that will become
       the master eventually. On 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 has a CNAME record
       that points to instead of

You are now done and should be able to retire the
fairly soon.

        -- Mark
Version: GnuPG v1.2.3 (FreeBSD)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]