Re: CVS Create new repository

[Zenin]

Subhodini Fernandes <address@hidden> wrote:
: I have setup CVS on a Solaris server. I plan to migrate the repository to
: another Solaris box. I copied all the files from the first server to the
: second into the correct directories and changed the information in the
: .cvspass file. However, the client does not see the new repository. It
: does not even authenticate the users who are setup in the new repository.

        When you say the .cvspass file, you're refering to the *clients'*
        .cvspass file I hope?  The server has no .cvspass file.

        How are your clients "setup" in the new repository?  Are you
        using the system's /etc/passwd file for CVS accounts, or
        $CVSROOT/passwd?  If it's the second case, do you have all the
        users also in /etc/passwd so the file ownerships will be valid? 
        Have you insured the /etc/passwd entries have the same numeric UIDs
        as the first repository?

        When you say the client "does not see" the new repository, have you
        set your $CVSROOT env var to point to the new location?

        If all the above checks out, are you trying to use an existing
        sandbox against the new repository?  Each sandbox retains its own
        settings about where the repository is (via CVS/Root).  If the new
        repository has a new hostname, you'll need all the clients to get
        new checkouts.

: Is there any way I can achieve this or do I have to create a new
: respository and then copy all files from the old server to the new one
: ?

        A repository move typically works like this:

        Turn off all access to the repository, typically by disabling the
        cvs server in /etc/inetd.conf and doing a kill -HUP on inetd.

        Copy over the repository using tar as root! -Don't use cp or rcp,
        you'll more then likely hoze all the file ownerships.

        Sync the new /etc/passwd file with the old repository.  Even if
        you're not using /etc/passwd for the passwords, you'll need to
        insure all the UIDs are the same for both systems.

        Change the DNS so that the new repository gets the cvs server's
        hostname.  It's best to use an alias, like cvs.yourcompany.com, then
        to use a "real" hostname like fred.yourcompany.com.

        Turn on cvs on the new server via inetd.conf, kill -HUP.


        Now, if you've done all of the above INCLUDING MOVING THE HOSTNAME
        DNS OVER, the move should be "transparent" to your clients.  That
        is, they should not need to re-checkout anything or such.  If you
        are instead using a new hostname, you WILL need every client to do a
        new "cvs login" and re-checkout all local sandboxes.

-- 
Z   R                   /\          _  _               _  _
E   H                  /  \  |  |  |_ | _ |  /\  |\ | /  |_
N @ P . O             /    \ |_ |_ |_ \_/ | /  \ | \| \_ |_
I   S   R              "The Greatest Game You Never Played"
N       G                     www.AllegianceHQ.org
>From address@hidden Wed Oct 09 15:05:14 2002
Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10)
        id 17zM8w-00031h-00
        for address@hidden; Wed, 09 Oct 2002 15:05:14 -0400
Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10)
        id 17zM8u-00030m-00
        for address@hidden; Wed, 09 Oct 2002 15:05:13 -0400
Received: from beta.dmz-us.st.com ([167.4.1.35])
        by monty-python.gnu.org with esmtp (Exim 4.10)
        id 17zM8t-00030h-00
        for address@hidden; Wed, 09 Oct 2002 15:05:11 -0400
Received: from zeta.dmz-us.st.com (zeta.dmz-us.st.com [167.4.80.115])
        by beta.dmz-us.st.com (STMicroelectronics) with SMTP id D9F0E4A07
        for <address@hidden>; Wed,  9 Oct 2002 19:05:05 +0000 (GMT)
Received: by zeta.dmz-us.st.com (STMicroelectronics, from userid 0)
        id C0E2448C4B; Wed,  9 Oct 2002 19:05:05 +0000 (GMT)
Received: from phxmail.phx.st.com (localhost [127.0.0.1])
        by zeta.dmz-us.st.com (STMicroelectronics) with ESMTP id 3B6E2535C7
        for <address@hidden>; Wed,  9 Oct 2002 19:05:05 +0000 (GMT)
Received: from localhost (address@hidden)MAA22054
        for <address@hidden>; Wed, 9 Oct 2002 12:05:03 -0700 (MST)
From: address@hidden
X-OpenMail-Hops: 1
Message-Id: <address@hidden>
MIME-Version: 1.0
To: address@hidden
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
        ;Creation-Date="Wed, 9 Oct 2002 11:25:22 -0700"
        ;Modification-Date="Wed, 9 Oct 2002 12:05:03 -0700"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 09 Dec 2002 08:52:57 -0500
Subject: cvs diff on repository files
X-BeenThere: address@hidden
X-Mailman-Version: 2.1b5
Precedence: list
List-Id: Announcements and discussions for the CVS version control system
 <info-cvs.gnu.org>
List-Help: <mailto:address@hidden>
List-Post: <mailto:address@hidden>
List-Subscribe: <http://mail.gnu.org/mailman/listinfo/info-cvs>,
        <mailto:address@hidden>
List-Archive: <http://mail.gnu.org/pipermail/info-cvs>
List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/info-cvs>,
        <mailto:address@hidden>
Date: Mon, 09 Dec 2002 13:52:57 -0000
X-Original-Date: Wed, 9 Oct 2002 12:05:03 -0700
X-List-Received-Date: Mon, 09 Dec 2002 13:52:57 -0000

Hello,

I'm wanting to set up CVS to automatically mail a cvs diff whenever a
file is committed.  The problem is cvs diff doesn't seem to work from the
repository, I get the following error:

cvs diff: Cannot open CVS/Entries for reading: No such file or directory

I set up CVSROOT/loginfo with the following line:

DEFAULT $CVSROOT/CVSROOT/cvsdiff.pl %{sVv} >> ~/cvsdiff.log

The cvsdiff.pl script does a cvs diff between the two revisions of each
file and emails it to a mailing list for code review.  But the cvs diff
inside the script fails.  Is there a solution that doesn't involve
checking the directory out on the repository server, doing the diff, and
removing the directory?  I noticed that the log.pl in the contrib
directory does a cvs status, which also fails for me with a similar
message if run on repository files.

Thanks,
Aaron