[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CVS Create new repository
From: |
Zenin |
Subject: |
Re: CVS Create new repository |
Date: |
Mon, 09 Dec 2002 13:52:51 -0000 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: CVS Create new repository,
Zenin <=