Re: CVS Problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Manuel Ledesma [EMAIL PROTECTED] writes: I was using CVS in local machine fine; running on top of Fedore Core 4. my cvs version is 1.11.20 and after updating my system, I started getting this error: cvs [login aborted]: unrecognized auth response from localhost: cvs pserver: cannot open /var/cvs/CVSROOT/config: Permission denied It means that the /var/cvs/CVSROOT/config file on your system may not be read due to a permissions problem. One presumes that you have set CVSROOT=:pserver:hostname:/var/cvs on the machine, but that your /var/cvs/CVSROOT/config file has insufficient permissions to allow read by either root and/or the user doing the 'cvs login' command. Check your local filesystem permissions for / /var /var/cvs /var/cvs/CVSROOT /var/cvs/CVSROOT/config ... are any of those directories mounted via NFS? If so, then you may need to worry about the filesystem under the mount point as well. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCZ4/M3x41pRYZE/gRAmspAJ9ajMxiwPryxfEb/gkAk2pJNmyJHgCfeMJp 3bzThg7d9qmxS84vjgMcSOM= =GAB2 -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS Problem
Mark D. Baushke wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Manuel Ledesma [EMAIL PROTECTED] writes: I was using CVS in local machine fine; running on top of Fedore Core 4. my cvs version is 1.11.20 and after updating my system, I started getting this error: cvs [login aborted]: unrecognized auth response from localhost: cvs pserver: cannot open /var/cvs/CVSROOT/config: Permission denied It means that the /var/cvs/CVSROOT/config file on your system may not be read due to a permissions problem. One presumes that you have set CVSROOT=:pserver:hostname:/var/cvs on the machine, but that your /var/cvs/CVSROOT/config file has insufficient permissions to allow read by either root and/or the user doing the 'cvs login' command. Check your local filesystem permissions for / /var /var/cvs /var/cvs/CVSROOT /var/cvs/CVSROOT/config ... are any of those directories mounted via NFS? If so, then you may need to worry about the filesystem under the mount point as well. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCZ4/M3x41pRYZE/gRAmspAJ9ajMxiwPryxfEb/gkAk2pJNmyJHgCfeMJp 3bzThg7d9qmxS84vjgMcSOM= =GAB2 -END PGP SIGNATURE- I checked the permission and they looked OK, I'm not using NFS. Here is the list of files from CVSROOT: -r--r--r-- 1 cvsuser root 495 Apr 20 22:30 checkoutlist -r--r--r-- 1 cvsuser root 699 Apr 20 22:29 checkoutlist,v -r--r--r-- 1 cvsuser root 760 Apr 20 22:30 commitinfo -r--r--r-- 1 cvsuser root 964 Apr 20 22:29 commitinfo,v -r--r--r-- 1 cvsuser root 990 Apr 20 22:30 config -r--r--r-- 1 cvsuser root 1353 Apr 20 22:30 config,v -r--r--r-- 1 cvsuser root 602 Apr 20 22:30 cvswrappers -r--r--r-- 1 cvsuser root 806 Apr 20 22:29 cvswrappers,v -r--r--r-- 1 cvsuser root 1025 Apr 20 22:30 editinfo -r--r--r-- 1 cvsuser root 1229 Apr 20 22:29 editinfo,v -rw-rw-rw- 1 cvsuser root 84 Apr 20 22:30 history -r--r--r-- 1 cvsuser root 1141 Apr 20 22:30 loginfo -r--r--r-- 1 cvsuser root 1345 Apr 20 22:29 loginfo,v -r--r--r-- 1 cvsuser root 1151 Apr 20 22:30 modules -r--r--r-- 1 cvsuser root 1355 Apr 20 22:29 modules,v -r--r--r-- 1 cvsuser root 564 Apr 20 22:30 notify -r--r--r-- 1 cvsuser root 768 Apr 20 22:29 notify,v -rw-r--r-- 1 cvsuser root 31 Apr 20 22:34 passwd -r--r--r-- 1 cvsuser root 649 Apr 20 22:30 rcsinfo -r--r--r-- 1 cvsuser root 853 Apr 20 22:29 rcsinfo,v -r--r--r-- 1 cvsuser root 879 Apr 20 22:30 taginfo -r--r--r-- 1 cvsuser root 1083 Apr 20 22:29 taginfo,v -rw-rw-rw- 1 cvsuser root0 Apr 20 22:29 val-tags -r--r--r-- 1 cvsuser root 1026 Apr 20 22:30 verifymsg -r--r--r-- 1 cvsuser root 1230 Apr 20 22:29 verifymsg,v ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS Problem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Manuel Ledesma [EMAIL PROTECTED] writes:
Mark D. Baushke wrote:
Manuel Ledesma [EMAIL PROTECTED] writes:
I was using CVS in local machine fine; running on top of Fedore Core 4.
my cvs version is 1.11.20 and after updating my system, I started
getting this error:
cvs [login aborted]: unrecognized auth response from localhost: cvs
pserver: cannot open /var/cvs/CVSROOT/config: Permission denied
I checked the permission and they looked OK, I'm not using NFS.
Here is the list of files from CVSROOT:
-r--r--r-- 1 cvsuser root 495 Apr 20 22:30 checkoutlist
-r--r--r-- 1 cvsuser root 699 Apr 20 22:29 checkoutlist,v
-r--r--r-- 1 cvsuser root 760 Apr 20 22:30 commitinfo
-r--r--r-- 1 cvsuser root 964 Apr 20 22:29 commitinfo,v
-r--r--r-- 1 cvsuser root 990 Apr 20 22:30 config
-r--r--r-- 1 cvsuser root 1353 Apr 20 22:30 config,v
-r--r--r-- 1 cvsuser root 602 Apr 20 22:30 cvswrappers
-r--r--r-- 1 cvsuser root 806 Apr 20 22:29 cvswrappers,v
-r--r--r-- 1 cvsuser root 1025 Apr 20 22:30 editinfo
-r--r--r-- 1 cvsuser root 1229 Apr 20 22:29 editinfo,v
-rw-rw-rw- 1 cvsuser root 84 Apr 20 22:30 history
-r--r--r-- 1 cvsuser root 1141 Apr 20 22:30 loginfo
-r--r--r-- 1 cvsuser root 1345 Apr 20 22:29 loginfo,v
-r--r--r-- 1 cvsuser root 1151 Apr 20 22:30 modules
-r--r--r-- 1 cvsuser root 1355 Apr 20 22:29 modules,v
-r--r--r-- 1 cvsuser root 564 Apr 20 22:30 notify
-r--r--r-- 1 cvsuser root 768 Apr 20 22:29 notify,v
-rw-r--r-- 1 cvsuser root 31 Apr 20 22:34 passwd
-r--r--r-- 1 cvsuser root 649 Apr 20 22:30 rcsinfo
-r--r--r-- 1 cvsuser root 853 Apr 20 22:29 rcsinfo,v
-r--r--r-- 1 cvsuser root 879 Apr 20 22:30 taginfo
-r--r--r-- 1 cvsuser root 1083 Apr 20 22:29 taginfo,v
-rw-rw-rw- 1 cvsuser root0 Apr 20 22:29 val-tags
-r--r--r-- 1 cvsuser root 1026 Apr 20 22:30 verifymsg
-r--r--r-- 1 cvsuser root 1230 Apr 20 22:29 verifymsg,v
The permissions look okay. You probably want to add the -t switch
cvs -t -d :pserver:localhost:/var/cvs login
to see if you can glean any more information about what is failing.
It could be some kind of bad argument to your xinetd.conf configuration
What do you have in /etc/xinetd.d/cvspserver ?
Does it look something like this?
--- cut here for sample /etc/xinetd.d/cvspserver ---
# default: on
# description: The CVS pserver is one of the most \
# insecure of protocols. It is not recommended \
# that you even consider using this on a network \
# where any potentially malicious users or viruses \
# might be able to attack it. Please consider \
# moving to use the :ext: method with CVS_RSH=ssh \
# in user environments as an alternative.
service cvspserver
{
port= 2401
socket_type = stream
protocol= tcp
wait= no
user= root
passenv = PATH
server = /usr/bin/cvs
server_args = -f --allow-root=/var/cvs pserver
}
--- cut here for sample /etc/xinetd.d/cvspserver ---
Good luck,
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFCZ7Y63x41pRYZE/gRAtmOAJ9x8nB5SzQg/73D5+S277Dt7Qyo7wCgt+pe
660j5OswJOQwE7zPHsXXW8w=
=YWKF
-END PGP SIGNATURE-
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS Problem
Mark D. Baushke wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Manuel Ledesma [EMAIL PROTECTED] writes:
Mark D. Baushke wrote:
Manuel Ledesma [EMAIL PROTECTED] writes:
I was using CVS in local machine fine; running on top of Fedore Core 4.
my cvs version is 1.11.20 and after updating my system, I started
getting this error:
cvs [login aborted]: unrecognized auth response from localhost: cvs
pserver: cannot open /var/cvs/CVSROOT/config: Permission denied
I checked the permission and they looked OK, I'm not using NFS.
Here is the list of files from CVSROOT:
-r--r--r-- 1 cvsuser root 495 Apr 20 22:30 checkoutlist
-r--r--r-- 1 cvsuser root 699 Apr 20 22:29 checkoutlist,v
-r--r--r-- 1 cvsuser root 760 Apr 20 22:30 commitinfo
-r--r--r-- 1 cvsuser root 964 Apr 20 22:29 commitinfo,v
-r--r--r-- 1 cvsuser root 990 Apr 20 22:30 config
-r--r--r-- 1 cvsuser root 1353 Apr 20 22:30 config,v
-r--r--r-- 1 cvsuser root 602 Apr 20 22:30 cvswrappers
-r--r--r-- 1 cvsuser root 806 Apr 20 22:29 cvswrappers,v
-r--r--r-- 1 cvsuser root 1025 Apr 20 22:30 editinfo
-r--r--r-- 1 cvsuser root 1229 Apr 20 22:29 editinfo,v
-rw-rw-rw- 1 cvsuser root 84 Apr 20 22:30 history
-r--r--r-- 1 cvsuser root 1141 Apr 20 22:30 loginfo
-r--r--r-- 1 cvsuser root 1345 Apr 20 22:29 loginfo,v
-r--r--r-- 1 cvsuser root 1151 Apr 20 22:30 modules
-r--r--r-- 1 cvsuser root 1355 Apr 20 22:29 modules,v
-r--r--r-- 1 cvsuser root 564 Apr 20 22:30 notify
-r--r--r-- 1 cvsuser root 768 Apr 20 22:29 notify,v
-rw-r--r-- 1 cvsuser root 31 Apr 20 22:34 passwd
-r--r--r-- 1 cvsuser root 649 Apr 20 22:30 rcsinfo
-r--r--r-- 1 cvsuser root 853 Apr 20 22:29 rcsinfo,v
-r--r--r-- 1 cvsuser root 879 Apr 20 22:30 taginfo
-r--r--r-- 1 cvsuser root 1083 Apr 20 22:29 taginfo,v
-rw-rw-rw- 1 cvsuser root0 Apr 20 22:29 val-tags
-r--r--r-- 1 cvsuser root 1026 Apr 20 22:30 verifymsg
-r--r--r-- 1 cvsuser root 1230 Apr 20 22:29 verifymsg,v
The permissions look okay. You probably want to add the -t switch
cvs -t -d :pserver:localhost:/var/cvs login
to see if you can glean any more information about what is failing.
It could be some kind of bad argument to your xinetd.conf configuration
What do you have in /etc/xinetd.d/cvspserver ?
Does it look something like this?
--- cut here for sample /etc/xinetd.d/cvspserver ---
# default: on
# description: The CVS pserver is one of the most \
# insecure of protocols. It is not recommended \
# that you even consider using this on a network \
# where any potentially malicious users or viruses \
# might be able to attack it. Please consider \
# moving to use the :ext: method with CVS_RSH=ssh \
# in user environments as an alternative.
service cvspserver
{
port= 2401
socket_type = stream
protocol= tcp
wait= no
user= root
passenv = PATH
server = /usr/bin/cvs
server_args = -f --allow-root=/var/cvs pserver
}
--- cut here for sample /etc/xinetd.d/cvspserver ---
Good luck,
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFCZ7Y63x41pRYZE/gRAtmOAJ9x8nB5SzQg/73D5+S277Dt7Qyo7wCgt+pe
660j5OswJOQwE7zPHsXXW8w=
=YWKF
-END PGP SIGNATURE-
I really don't know what can be the cause? I changed my cvspserver file
to yours.
Here are my entries in services file ...
cvspserver 2401/tcp# CVS client/server
operations
cvspserver 2401/udp# CVS client/server
operations
cvs version 1.11.20
kernel version 2.6.11-1.1240_FC4
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS Problem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Manuel Ledesma [EMAIL PROTECTED] writes:
Mark D. Baushke wrote:
Manuel Ledesma [EMAIL PROTECTED] writes:
Mark D. Baushke wrote:
Manuel Ledesma [EMAIL PROTECTED] writes:
I was using CVS in local machine fine; running on top of Fedore Core 4.
my cvs version is 1.11.20 and after updating my system, I started
getting this error:
cvs [login aborted]: unrecognized auth response from localhost: cvs
pserver: cannot open /var/cvs/CVSROOT/config: Permission denied
I checked the permission and they looked OK, I'm not using NFS.
Here is the list of files from CVSROOT:
-r--r--r-- 1 cvsuser root 495 Apr 20 22:30 checkoutlist
-r--r--r-- 1 cvsuser root 699 Apr 20 22:29 checkoutlist,v
-r--r--r-- 1 cvsuser root 760 Apr 20 22:30 commitinfo
-r--r--r-- 1 cvsuser root 964 Apr 20 22:29 commitinfo,v
-r--r--r-- 1 cvsuser root 990 Apr 20 22:30 config
-r--r--r-- 1 cvsuser root 1353 Apr 20 22:30 config,v
-r--r--r-- 1 cvsuser root 602 Apr 20 22:30 cvswrappers
-r--r--r-- 1 cvsuser root 806 Apr 20 22:29 cvswrappers,v
-r--r--r-- 1 cvsuser root 1025 Apr 20 22:30 editinfo
-r--r--r-- 1 cvsuser root 1229 Apr 20 22:29 editinfo,v
-rw-rw-rw- 1 cvsuser root 84 Apr 20 22:30 history
-r--r--r-- 1 cvsuser root 1141 Apr 20 22:30 loginfo
-r--r--r-- 1 cvsuser root 1345 Apr 20 22:29 loginfo,v
-r--r--r-- 1 cvsuser root 1151 Apr 20 22:30 modules
-r--r--r-- 1 cvsuser root 1355 Apr 20 22:29 modules,v
-r--r--r-- 1 cvsuser root 564 Apr 20 22:30 notify
-r--r--r-- 1 cvsuser root 768 Apr 20 22:29 notify,v
-rw-r--r-- 1 cvsuser root 31 Apr 20 22:34 passwd
-r--r--r-- 1 cvsuser root 649 Apr 20 22:30 rcsinfo
-r--r--r-- 1 cvsuser root 853 Apr 20 22:29 rcsinfo,v
-r--r--r-- 1 cvsuser root 879 Apr 20 22:30 taginfo
-r--r--r-- 1 cvsuser root 1083 Apr 20 22:29 taginfo,v
-rw-rw-rw- 1 cvsuser root0 Apr 20 22:29 val-tags
-r--r--r-- 1 cvsuser root 1026 Apr 20 22:30 verifymsg
-r--r--r-- 1 cvsuser root 1230 Apr 20 22:29 verifymsg,v
The permissions look okay. You probably want to add the -t switch
cvs -t -d :pserver:localhost:/var/cvs login
to see if you can glean any more information about what is failing.
It could be some kind of bad argument to your xinetd.conf configuration
What do you have in /etc/xinetd.d/cvspserver ?
Does it look something like this?
--- cut here for sample /etc/xinetd.d/cvspserver ---
# default: on
# description: The CVS pserver is one of the most \
# insecure of protocols. It is not recommended \
# that you even consider using this on a network \
# where any potentially malicious users or viruses \
# might be able to attack it. Please consider \
# moving to use the :ext: method with CVS_RSH=ssh \
# in user environments as an alternative.
service cvspserver
{
port= 2401
socket_type = stream
protocol= tcp
wait= no
user= root
passenv = PATH
server = /usr/bin/cvs
server_args = -f --allow-root=/var/cvs pserver
}
--- cut here for sample /etc/xinetd.d/cvspserver ---
Good luck,
-- Mark
I really don't know what can be the cause? I changed my cvspserver
file to yours.
Did it help? (Mine was just an example I threw together, I was trying
to get you to provide information on your own configuration file.)
Here are my entries in services file ...
cvspserver 2401/tcp# CVS client/server
operations
cvspserver 2401/udp# CVS client/server
operations
cvs version 1.11.20
kernel version 2.6.11-1.1240_FC4
(Note: I have not yet played with FC4 myself...)
I don't see any 'cvs -t -d :pserver:localhost:/var/cvs login' output,
did I miss it?
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFCaCnx3x41pRYZE/gRAsmtAJ4zZ1Y5tnAw5LAL61yBwLHV22ZUGACgwFmU
/Odhh313SR1r0bxyqogX7yc=
=p7us
-END PGP SIGNATURE-
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS Problem
On Thursday 21 April 2005 17:27, Manuel Ledesma wrote: I was using CVS in local machine fine; running on top of Fedore Core 4. my cvs version is 1.11.20 and after updating my system, I started getting this error: Didn't CVS just move to the list of apps now under SELinux control? Could this be related? From a recent FC4 update selinux-policy-targeted-1.23.12-1 - * Wed Apr 20 2005 Dan Walsh [EMAIL PROTECTED] 1.23.12-1 - Fix dhcpc.te - fix hostname.te for targeted domain - Update from NSA * Added CVS and uucpd policy from Dan Walsh. Regards, Mike Klinke ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS Problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Klinke [EMAIL PROTECTED] writes: On Thursday 21 April 2005 17:27, Manuel Ledesma wrote: I was using CVS in local machine fine; running on top of Fedore Core 4. my cvs version is 1.11.20 and after updating my system, I started getting this error: Didn't CVS just move to the list of apps now under SELinux control? Could this be related? From a recent FC4 update selinux-policy-targeted-1.23.12-1 - * Wed Apr 20 2005 Dan Walsh [EMAIL PROTECTED] 1.23.12-1 - Fix dhcpc.te - fix hostname.te for targeted domain - Update from NSA * Added CVS and uucpd policy from Dan Walsh. I suppose that is possible. If so, then looking in http://www.nsa.gov/selinux/info/faq.cfm may be a good idea. You should also try reading this thread for ideas: http://lists.gnu.org/archive/html/info-cvs/2005-02/msg00274.html Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCaDoo3x41pRYZE/gRAlcqAJ966uy7a8wTL6mxli4FVYptRI+EggCfbGWw mwntH1fZ3+5SFmQTCS7tLHk= =mjIK -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS Problem
Mark D. Baushke wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Klinke [EMAIL PROTECTED] writes:
On Thursday 21 April 2005 17:27, Manuel Ledesma wrote:
I was using CVS in local machine fine; running on top of
Fedore Core 4. my cvs version is 1.11.20 and after updating
my system, I started getting this error:
Didn't CVS just move to the list of apps now under SELinux control?
Could this be related?
From a recent FC4 update
selinux-policy-targeted-1.23.12-1
-
* Wed Apr 20 2005 Dan Walsh [EMAIL PROTECTED] 1.23.12-1
- Fix dhcpc.te
- fix hostname.te for targeted domain
- Update from NSA
* Added CVS and uucpd policy from Dan Walsh.
I suppose that is possible. If so, then looking in
http://www.nsa.gov/selinux/info/faq.cfm
may be a good idea.
You should also try reading this thread for ideas:
http://lists.gnu.org/archive/html/info-cvs/2005-02/msg00274.html
Good luck,
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFCaDoo3x41pRYZE/gRAlcqAJ966uy7a8wTL6mxli4FVYptRI+EggCfbGWw
mwntH1fZ3+5SFmQTCS7tLHk=
=mjIK
-END PGP SIGNATURE-
Thanks everybody, I solved the problem by adding my machine to
hosts.allow, thanks by brinthig this out.
This two command help to find the problem :
ps ax |grep xinetd |grep -v grep |awk {print $1}
strace -f -o /tmp/zzz -p [pid - tooked from previos command]
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
CVS Problem
I was using CVS in local machine fine; running on top of Fedore Core 4. my cvs version is 1.11.20 and after updating my system, I started getting this error: cvs [login aborted]: unrecognized auth response from localhost: cvs pserver: cannot open /var/cvs/CVSROOT/config: Permission denied I would really appreciate your help, because this is really affecting my college project. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
CVS Problem : Broken Sync?
Hi, I can't connect to CVS anymore without getting the following error: --- [EMAIL PROTECTED]/usr/local/CVS#cvs login Logging in to :pserver:[EMAIL PROTECTED]:2401/usr/local/CVS CVS password: cvs [login aborted]: unrecognized auth response from 123.123.com: cvs pserver: /usr/local/CVS/CVSROOT/config: unrecognized keyword 'UseNewInfoFmtStrings' --- After a search of Google*, I believe it is a problem on the server side caused by broken sync and that the pserver interface slightly busted. Can anyone tell me how to fix it, or perhaps how I broke it? - Best regards, Lee *[http://www.google.com/search?q=unrecognized+keyword+UseNewInfoFmtStringshl=enlr=ie=UTF-8start=0sa=N] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS Problem : Broken Sync?
Lee writes: cvs [login aborted]: unrecognized auth response from 123.123.com: cvs pserver: /usr/local/CVS/CVSROOT/config: unrecognized keyword 'UseNewInfoFmtStrings' Your $CVSROOT/CVSROOT/config file contains entries that are only supported by the 1.12 releases of CVS but the server you're running is an older release. Either update the server or remove the offending lines from the config file. -Larry Jones These findings suggest a logical course of action. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Regarding CVS Problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Saurabh Pradhan [EMAIL PROTECTED] writes: Thanks Mark, I appreciate that help. To avoid tags usage upto this extent how do i manage my releases, any suggestions?? There are as many ways to manage releases as there software companies. There is nothing fundamentally wrong with tagging lots of stuff. For myself, I think you may find that rolling up multiple bug fixes into a single release tag might be more productive in the general case. For example, you may wish to associate the tag with a field in the bug tracking system... then you can get a list of bugs fixed in a given release and have your one release to many fixed bugs release strategy that lists the bugs fixed by the next release of your product. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAoIrc3x41pRYZE/gRAsDHAJ9fh6cH9ogwO1u9VQozk92eWxSc1gCg3SCW x001NLeJUIeTpjXZfoPuqkE= =Ne46 -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs problem under cygwin, cvs documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: Although we have a moderately good workaround (an old version of cvs compiled up), we have a long-standing problem with cvs in Cygwin that I'm looking into finally. We get responses like: My Cygwin compilation works fine and even passes the test suite using :ext: ssh to another machine running the CVS server, but my Cygwin installation is set to use UNIX EOLs and not Windows. I believe this was a compile-time option. Ah, one other difference is that our /opt/bin/cvs version does not complain about CVSROOT starting with :server:, so the real question may be: why doesn't the Cygwin version include that? I'm not sure, but I think whether the :server: method is compiled or not might only be based on an #ifdef. Check the windows-NT/* code in the CVS source distribution. The only reason :server: was supplied at all for Windows was that Windows xomes with a broken RSH implementation, hrm... that performs some sort of EOL conversion... Is it possible that your Cygwin CVS is using the Windows RSH client rather than the Cygwin RSH? Again, I've had few recent troubles with the Cygwin client under Windows and it can pass the test suite in a variety of ways. I once had troubles mixing the Cygwin CVS with a Windows CVS in the same sandbox since the Windows version was saving carriage returns into the CVS/Root files which Cygwin would later interpret as part of the repository string. Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQFAVzDXLD1OTBfyMaQRAjCqAKDzeAlI7CzIGSH0PkGXwYkUue3tnACg3lmq rwfNI50DUX97xZMzRlITuVg= =Lq5x -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs problem under cygwin, cvs documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: Concurrent Versions System (CVS) 1.11.6 (client/server) P.S., 1.11.6 is getting pretty old. You should consider upgrading to 1.11.14. A lot of bug fixes have gone in since 1.11.6, some specific to Cygwin, at least in the test suite and at least one more. Please browse the NEWS file for more information. Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQFAVzIfLD1OTBfyMaQRAv59AKDSP2bYxgVac1ishNcKeaGngl9Y/wCaAxQd 2klIXlPDRaLZcthy4vFIosE= =6/al -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs problem under cygwin, cvs documentation
I wrote: Although we have a moderately good workaround (an old version of cvs compiled up), we have a long-standing problem with cvs in Cygwin that I'm looking into finally. We get responses like: In case you didn't see my other warning post, I'll repeat it here: I just sent the same question to this list and to the cygwin mailing list (I'm subscribed to both, obviously). Don't Reply-All to that post. I was automatically marked as a spammer by sending one email to both lists, even though the problem could be either a cygwin one or a cvs one. I'd hate to think that a helpful reply to my query might get someone else blocked. luke ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs problem under cygwin, cvs documentation
Although we have a moderately good workaround (an old version of cvs compiled up), we have a long-standing problem with cvs in Cygwin that I'm looking into finally. We get responses like: $ /usr/bin/cvs update [EMAIL PROTECTED]'s password: ' from cvs serverng: unrecognized response `ok cvs [update aborted]: received interrupt signal Killed by signal 2. Which of course is newline conversion problems: $ /usr/bin/cvs update 21 | od -c [EMAIL PROTECTED]'s password: 000 c v s u p d a t e : w a r n 020 i n g : u n r e c o g n i z e 040 d r e s p o n s e ` o k \r ' 060 f r o m c v s s e r v e r A message from 2002 to the cvs mailing list suggested using the access method :server: instead of the default :ext:. I added this to CVSROOT like so: CVSROOT=:server:cvs.research.canon.com.au:/u/cvs but that had no effect on existing checkouts because of the existing CVS/Root file, but after editing that to insert the :server: at the front: $ cat CVS/Root :server:cvs.research.canon.com.au:/u/cvs I got this response: $ /usr/bin/cvs update cvs [update aborted]: the :server: access method is not supported by this port of CVS Any suggestions? I notice that none of the :ext: or :server: stuff is written up in the CVS man page. I'll have a read through the FAQ. Erk. Our local copy is 1993. Erk. The CVS FAQ at http://ccvs.cvshome.org/fom//cache/1.html doesn't appear to be available as a single file, and doesn't seem to be as comprehensive as the old FAQ anyway. http://www.cvshome.org/docs/#s3 points at the old CVS site, but the good FAQ doesn't exist there either. Oh well. I suppose it's really a Cygwin problem, because a version someone once compiled up here is okay. I see it's just a client version, not a client/server version. Working version of cvs under Windows/Cygwin: $ /opt/bin/cvs --version Concurrent Versions System (CVS) 1.10 `Halibut' (client) Copyright (c) 1989-1998 Brian Berliner, david d `zoo' zuhn, Jeff Polk, and other authors CVS may be copied only under the terms of the GNU General Public License, a copy of which can be found with the CVS distribution kit. Specify the --help option for further information about CVS Broken version of cvs under Windows/Cygwin: $ /usr/bin/cvs --version Concurrent Versions System (CVS) 1.11.6 (client/server) Copyright (c) 1989-2003 Brian Berliner, david d `zoo' zuhn, Jeff Polk, and other authors CVS may be copied only under the terms of the GNU General Public License, a copy of which can be found with the CVS distribution kit. Specify the --help option for further information about CVS Ah, one other difference is that our /opt/bin/cvs version does not complain about CVSROOT starting with :server:, so the real question may be: why doesn't the Cygwin version include that? luke ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Cvs problem
Hi Guys, I'm having a problem with vss2cvs.pl the problem is that when the script tries to concatenate $currdir with $dirline it seems to copy one over the other rather than next to each other. i.e $currfile should be cvsrepository/hi.txt however it ends up being hi.txtository Heres that part of the code: $currfile = $currdir$dirline; open(FILETYPE,ss Filetype \$currfile\ $ssuserpass |); $type = lc(FILETYPE); close(FILETYPE); Does anyone know how to fix this. Please help as I'm only a student in 2nd year at University and have never really used perl or cvs. Thanks, James We can all fly, it's just a definition of how we do it! James McIntosh http://www.geocities.com/mac010382 _ Send and receive Hotmail on your mobile device: http://mobile.msn.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: vss2cvs.pl problem (Was: Cvs problem)
--- Jim McIntosh [EMAIL PROTECTED] wrote: I'm having a problem with vss2cvs.pl the problem is that when the script tries to concatenate $currdir with $dirline it seems to copy one over the other rather than next to each other. i.e $currfile should be cvsrepository/hi.txt however it ends up being hi.txtository Heres that part of the code: $currfile = $currdir$dirline; open(FILETYPE,ss Filetype \$currfile\ $ssuserpass |); $type = lc(FILETYPE); close(FILETYPE); Does anyone know how to fix this. Please help as I'm only a student in 2nd year at University and have never really used perl or cvs. It looks like the initial (ie on the right-hand-side of the assignment) value of $currdir has a '\r' in it. My guess is that you're on a Windows machine. Is this correct? Are you using Cygwin? If so, are you using Cygwin's perl and are you using a binary-mounted directory? If all you want to do is get this script working, you can do a chop($currdir) before the assignment. I would think, though, that you'll run into other similar problems with the script and even line-ending problems later on with CVS if you are, in fact, running on a text-mounted directory. Noel __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: vss2cvs.pl problem (Was: Cvs problem)
Hi Noel,Yeah I'm on a windows machine(windows 2000 service pack 2) and I am using cygwin too. I have installed Activeperl 5.6 but I was previously using Cygwins perl.I tried chomp before I tried to concatenate the two strings into $currfile but it didn't seem to work as the same error came up. Thanks for your help, James From: Noel Yap <[EMAIL PROTECTED]> To: Jim McIntosh <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: vss2cvs.pl problem (Was: Cvs problem) Date: Thu, 11 Jul 2002 06:57:13 -0700 (PDT) --- Jim McIntosh <[EMAIL PROTECTED]>wrote: I'm having a problem with vss2cvs.pl the problem is that when the script tries to concatenate $currdir with $dirline it seems to copy one over the other rather than next to each other. i.e $currfile should be cvsrepository/hi.txt however it ends up being hi.txtository Heres that part of the code: $currfile = "$currdir$dirline"; open(FILETYPE,"ss Filetype \"$currfile\" $ssuserpass |"); $type = lc(); close(FILETYPE); Does anyone know how to fix this. Please help as I'm only a student in 2nd year at University and have never really used perl or cvs. It looks like the initial (ie on the right-hand-side of the assignment) value of $currdir has a '\r' in it. My guess is that you're on a Windows machine. Is this correct? Are you using Cygwin? If so, are you using Cygwin's perl and are you using a binary-mounted directory? If all you want to do is get this script working, you can do a chop($currdir) before the assignment. I would think, though, that you'll run into other similar problems with the script and even line-ending problems later on with CVS if you are, in fact, running on a text-mounted directory. Noel Join the worlds largest e-mail service with MSN Hotmail. Click Here ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS problem
Hi all, I've posted a question about CVS migration two days ago and with your help I'm able to successfully login to the server, but now I've a new problem. Can any of you gurus please help. The problem is a below cvs server: cannot open /root/.cvsignore: Permission denied cvs [server aborted]: can't chdir(/root): Permission denied I've read the CVS manual but didnt understand the solution. I'd really appreciate if any of you can please guide me on this issue. Regards, Peram _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS problem
Sudhaker P writes: cvs server: cannot open /root/.cvsignore: Permission denied cvs [server aborted]: can't chdir(/root): Permission denied Make sure you have a -f option in your [x]inetd configuration (just before the --allow-root option is a good place). -Larry Jones I wonder if I can grow fangs when my baby teeth fall out. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
another CVS problem
Hi, Larry's solution helped me out of the problems .Thanks a lot folks, that really helped.I was able to go to the directories but I'm facing a new problem when I'm checking out files from the repository: cvs server: Updating /DesignDocuments cvs server: failed to create lock directory for `/usr/local/cvsrepos/DesignDocuments' (/usr/local/cvsrepos/DesignDocuments/#cvs.lock): Permission denied cvs server: failed to obtain dir lock in repository `/usr/local/cvsrepos/DesignDocuments' cvs [server aborted]: read lock failed - giving up Can you please give me some insight on how I can solve this problem. Any suggestions will be greately appreciated. Sincerely, peram _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: another CVS problem
Hi, Larry's solution helped me out of the problems .Thanks a lot folks, that really helped.I was able to go to the directories but I'm facing a new problem when I'm checking out files from the repository: cvs server: Updating /DesignDocuments cvs server: failed to create lock directory for `/usr/local/cvsrepos/DesignDocuments' (/usr/local/cvsrepos/DesignDocuments/#cvs.lock): Permission denied This is because you do not have write permissions for that directory. I don't know why you wouldn't, and there are several possibilities. Are you supposed to have full or read-only access there? What access method are you using? Do you have a real account on the server machine? What OS is the server running? Is the administrator using Unix groups to control access, or ACLs? David H. Thornley| If you want my opinion, ask. [EMAIL PROTECTED] | If you don't, flee. http://www.thornley.net/~thornley/david/ | O- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS problem
I am having problems connecting to a CVS server I am attempting to configure. I believe I have setup the server per all the Documentation I can find but I recieve the following message when I attempt to connect with WinCVS. cvs [login aborted]: connect to xxx.xxx.xxx.xxx:2401 failed: Connection refused I am using Redhat 7.2 with the default install version of CVS. 2401 is listed in my services file. I have defined CVSROOT in WinCVS as: :pserver:[EMAIL PROTECTED]:/home/cvsroot Anyone have any suggestions? __ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs problem with modules, please help!
If you can describe in detail, what You are trying to do, then that will be helpful. Since If you check the help of -d option. it says the module will go into the directory, instead of the module name. For example module -d dir is place module in the directory dir instead of module Please specify the purpose. Swapnil [EMAIL PROTECTED] (Sergey Malov) wrote in message news:[EMAIL PROTECTED]... [EMAIL PROTECTED] (Eugene Katzman) wrote in message news:[EMAIL PROTECTED]... [EMAIL PROTECTED] (Sergey Malov) wrote in message news:[EMAIL PROTECTED]... I found the following addition to the CVS's modules file doesn't work as it suppose, according to some posts whcih I've seen in this group foo -d . proj1/subproj1 file1.pl where $CVSROOT/proj1/subproj1/file1.pl does exists. When I'm trying to checkout file1.pl, I'm getting message: cvs server: existing repository /home/users/cvs/CVSROOT doesn't match /home/users/cvs/CVSROOT/proj1/subproj1 cvs server: ignoring module foo I'm sure that /home/users/cvs/CVSROOT/proj1/subproj1 does exists with the forementioned file. I'm sure that CVSROOT points to correct place and work for other modules. Have you checked out the directory structure, ie Subproj1 with its accompanying directories. Is there a CVSROOT directory in the repository and does it have the files which would have been created when an init command was performed. Yes, CVSROOT exists and has all the needed files. Tree proj1/subproj1 also exists and has all the files which need. Greg Woods mentioned, however, that construction which I'm trying to use: foo -d . proj1/subproj1 file1.pl is illegal in CVS and if it is indeed the case, I understand why error message shows up. Sergey Malov ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs problem
I often happen this problem that authorization failed: server rejected access to /home/cvsroot for user cvs or used empty password ;try "cvs login"with a real password
Re: cvs problem with modules, please help!
[EMAIL PROTECTED] (Sergey Malov) wrote in message news:[EMAIL PROTECTED]... I found the following addition to the CVS's modules file doesn't work as it suppose, according to some posts whcih I've seen in this group foo -d . proj1/subproj1 file1.pl where $CVSROOT/proj1/subproj1/file1.pl does exists. When I'm trying to checkout file1.pl, I'm getting message: cvs server: existing repository /home/users/cvs/CVSROOT doesn't match /home/users/cvs/CVSROOT/proj1/subproj1 cvs server: ignoring module foo I'm sure that /home/users/cvs/CVSROOT/proj1/subproj1 does exists with the forementioned file. I'm sure that CVSROOT points to correct place and work for other modules. I'm not going to use the above mentioned line by itself, it's part of building some complex module. I use cvs 1.9.28 on Solaris 8. I would greatly appreciate any help, because I'm stuck. Thanks, Sergey Malov Have you checked out the directory structure, ie Subproj1 with its accompanying directories. Is there a CVSROOT directory in the repository and does it have the files which would have been created when an init command was performed. The files that should be there include checkoutlist, commitinfo, config, cvswrappers, editinfo, history, loginfo and other files. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs problem with modules, please help!
On Fri, Feb 22, 2002 at 04:01:24PM -0500, Greg A. Woods wrote: You can't use -d . -- you must specify a directory name other than '.' (you can't use .. in the name either, and I don't believe a sub-directory is legal either -- i.e. no relative pathnames, just a basic simple directory name) Actually, this works fine: foo -d fred/barney my/module/path Or is that not whay you meant relative pathname? Steve ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs problem with modules, please help!
[EMAIL PROTECTED] (Eugene Katzman) wrote in message news:[EMAIL PROTECTED]... [EMAIL PROTECTED] (Sergey Malov) wrote in message news:[EMAIL PROTECTED]... I found the following addition to the CVS's modules file doesn't work as it suppose, according to some posts whcih I've seen in this group foo -d . proj1/subproj1 file1.pl where $CVSROOT/proj1/subproj1/file1.pl does exists. When I'm trying to checkout file1.pl, I'm getting message: cvs server: existing repository /home/users/cvs/CVSROOT doesn't match /home/users/cvs/CVSROOT/proj1/subproj1 cvs server: ignoring module foo I'm sure that /home/users/cvs/CVSROOT/proj1/subproj1 does exists with the forementioned file. I'm sure that CVSROOT points to correct place and work for other modules. Have you checked out the directory structure, ie Subproj1 with its accompanying directories. Is there a CVSROOT directory in the repository and does it have the files which would have been created when an init command was performed. Yes, CVSROOT exists and has all the needed files. Tree proj1/subproj1 also exists and has all the files which need. Greg Woods mentioned, however, that construction which I'm trying to use: foo -d . proj1/subproj1 file1.pl is illegal in CVS and if it is indeed the case, I understand why error message shows up. Sergey Malov ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs problem with modules, please help!
I found the following addition to the CVS's modules file doesn't work as it suppose, according to some posts whcih I've seen in this group foo -d . proj1/subproj1 file1.pl where $CVSROOT/proj1/subproj1/file1.pl does exists. When I'm trying to checkout file1.pl, I'm getting message: cvs server: existing repository /home/users/cvs/CVSROOT doesn't match /home/users/cvs/CVSROOT/proj1/subproj1 cvs server: ignoring module foo I'm sure that /home/users/cvs/CVSROOT/proj1/subproj1 does exists with the forementioned file. I'm sure that CVSROOT points to correct place and work for other modules. I'm not going to use the above mentioned line by itself, it's part of building some complex module. I use cvs 1.9.28 on Solaris 8. I would greatly appreciate any help, because I'm stuck. Thanks, Sergey Malov ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs problem with modules, please help!
Sergey Malov writes: When I'm trying to checkout file1.pl, I'm getting message: cvs server: existing repository /home/users/cvs/CVSROOT doesn't match /home/users/cvs/CVSROOT/proj1/subproj1 cvs server: ignoring module foo That implies that you're trying to checkout files from different repository directories into the same working directory. CVS doesn't allow that. -Larry Jones Fortunately, that was our plan from the start. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs problem with modules, please help!
[ On , February 22, 2002 at 10:23:51 (-0800), Sergey Malov wrote: ] Subject: cvs problem with modules, please help! I found the following addition to the CVS's modules file doesn't work as it suppose, according to some posts whcih I've seen in this group foo -d . proj1/subproj1 file1.pl You can't use -d . -- you must specify a directory name other than '.' (you can't use .. in the name either, and I don't believe a sub-directory is legal either -- i.e. no relative pathnames, just a basic simple directory name) Where did you get the idea that you could use '.'? Wherever such a suggestion is it should be corrected A.S.A.P. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Baffling cvs problem
[apologies, the last message I sent was missing some data] We have a pair of CVS servers, both running Debian 3.0 (Linux), cvs version 1.11.1p1. We're using pserver. On one of the servers, projects with large files are having difficulties: the CVS process exits with output like this: cvs checkout hgia05s01 U hgia05s01/images/math/hgia/hgia.02.02.3.ex9.jpg U hgia05s01/images/math/hgia/hgia.03.03.3.ex08a.jpg U hgia05s01/images/math/hgia/hgia.03.03.3.ex08b.jpg U hgia05s01/images/math/hgia/hgia.05.06.3.ex07.jpg U hgia05s01/images/math/hgia/hgia.06.08.3.ex05.jpg U hgia05s01/images/math/hgia/hgia.08.01.3.ex02a.jpg U hgia05s01/images/math/hgia/hgia.08.01.3.ex02b.jpg U hgia05s01/images/math/hgia/hgia.08.01.3.ex02c.jpg U hgia05s01/images/math/hgia/hgia.08.01.4.05.jpg U hgia05s01/images/math/hgia/hgia.08.01.4.10.jpg U hgia05s01/images/math/hgia/hgia.08.02.4.95.jpg U hgia05s01/images/math/hgia/hgia.08.04.4.72.jpg U hgia05s01/images/math/hgia/hgia.09.02.3.ex02.jpg U hgia05s01/images/math/hgia/hgia.09.02.3.ex04.jpg U hgia05s01/images/math/hgia/hgia.11.02.ex04.jpg U hgia05s01/pincodes/placeholder.txt U hgia05s01/reference/placeholder.txt U hgia05s01/xml/hgia05s01_exercises.bca.xml cvs [checkout aborted]: end of file from server (consult above messages if any) As you can see, not a clue from cvs as to why it died. The docs I've been scouring for the entire day have been no help whatsoever, as they all seem to assume this problem happens only when using rsh. The other cvs server has no problems at all with the same respository. With the -t option set, here's what I see: S- Create_Admin (xml, hgia05s01/xml, /home/cvsroot/hgia05s01/xml, , , 0, 0) S- unlink_file(xml/CVS/Tag) - ParseInfo(/home/cvsroot/CVSROOT/rcsinfo, hgia05s01/xml, ALL) S- Create_Admin S- unlink_file(xml/CVS/Entries.Static) S- checkout (/home/cvsroot/hgia05s01/xml/hgia05s01_exercises.bca.xml,v, 1.1, -kk, (function)) - unlink_file(CVS/Tag) - rename(CVS/Entries.Backup,CVS/Entries) - unlink_file(CVS/Entries.Log) - Create_Admin (hgia05s01/xml, hgia05s01/xml, /home/cvsroot/hgia05s01/xml, , , 0, 0) - unlink_file(hgia05s01/xml/CVS/Tag) - Create_Admin - unlink_file(CVS/Tag) - unlink_file(CVS/Entries.Static) S- server_register(hgia05s01_exercises.bca.xml, 1.1, , -kk, , , ) S- Register(hgia05s01_exercises.bca.xml, 1.1, , -kk, ) U hgia05s01/xml/hgia05s01_exercises.bca.xml - rename(.new.hgia05s01,hgia05s01_exercises.bca.xml) - Register(hgia05s01_exercises.bca.xml, 1.1, Tue Feb 12 01:04:25 2002, -kk, ) S- unlink_file(CVS/Tag) S- rename(CVS/Entries.Backup,CVS/Entries) S- unlink_file(CVS/Entries.Log) S- Create_Admin (zebra, hgia05s01/zebra, /home/cvsroot/hgia05s01/zebra, , , 0, 0) S- unlink_file(zebra/CVS/Tag) - ParseInfo(/home/cvsroot/CVSROOT/rcsinfo, hgia05s01/zebra, ALL) S- Create_Admin S- unlink_file(zebra/CVS/Entries.Static) S- checkout (/home/cvsroot/hgia05s01/zebra/foo,v, 1.1, , (function)) S- server_register(foo, 1.1, , , , , ) S- Register(foo, 1.1, , , ) S- unlink_file(CVS/Tag) S- rename(CVS/Entries.Backup,CVS/Entries) S- unlink_file(CVS/Entries.Log) S- rename(CVS/Entries.Backup,CVS/Entries) S- unlink_file(CVS/Entries.Log) cvs [checkout aborted]: end of file from server (consult above messages if any) The confusing part is that the file it bombs out on (hgia05s01_exercises.bca.xml) is complete, but it fails to get any files from beyond that point. A second cvs checkout will complete the module, but that's not except for our end users. When I examine the other site with inetd -d, all I can glean is that cvs-pserver is exiting with exit code 100. Unfortunately, I don't know what options (if any) I can use to see what the actual failure in the server-side portion of cvs is, it's not logging anything in any log file that I can see. Any insight on this list? Thanks. -- Russ Taylor (http://www.cmc.net/~rtaylor/) Oooh, Marge, they have the internet on computers now! -- Homer Simpson ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Baffling cvs problem
Russ Taylor writes: cvs [checkout aborted]: end of file from server (consult above messages if any) As you can see, not a clue from cvs as to why it died. Try upgrading the server to the current development release of CVS -- I just made a change yesterday that should get you an error message in this case. -Larry Jones Philistines. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS problem
Hi ! I have a problem accessing a repository with a username I have created. I have 2 usernames, clasuser01 and nruser01 I also have 2 groups cvs-clas and cvs-nr I want to use the LockDir option so I have also created a group cvslock, which both users belong to. My problem is this... clasuser01 works perfectly he can access repository a, checkout code and commit it back again. I want him to access repository b in order to checkout code, but NOT commit back again. This works! I have given him writs access to the history file in each repository by putting him in the cvslock group. I have also changed the config files in each repository to add the line LockDir=/home/cvs/cvs-locks. As I have said this owrks fine. However, I have attempted to give the same permissions to nruser01, but when I try to do a checkout the system tries to write to a LockDir in the repository and NOT in the LockDir that I want to write to. Any help would be grateful thanks Steve PlattConfiguration ManagerRDF Consulting01273 20015007808 077538 This transmission is confidential and intended solely for the person or organisation to whom it is addressed. It may contain privileged and confidential information. If you are not the intended recipient, you should not copy, distribute or take any action in reliance on it. If you have received this transmission in error, please notify the sender immediately. Any opinions or advice contained in this e-mail are those of the individual sender except where they are stated to be the views of RDF Group or EMS plc. All messages passing through this gateway are virus scanned.
Re: CVS problem
Steve Platt writes: However, I have attempted to give the same permissions to nruser01, but when I try to do a checkout the system tries to write to a LockDir in the repository and NOT in the LockDir that I want to write to. That implies that you *don't* have LockDir set in the CVSROOT/config file for that repository. Check the actual file in the repository, not a checked-out version of it. -Larry Jones It's no fun to play games with a poor sport. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs problem
Make sure you have write permissions on the /develop/src/MAIN/vault/is/sap_intf_hq directory. Generally you want everyone in the same group who is doing development and you want rwx permissions for that group. You can enforce the correct directory permissions for when new directories are created by the group s bit. donald On Tue, Jan 08, 2002 at 10:30:54AM -0500, [EMAIL PROTECTED] wrote: To whom it may concern: I am getting this problem: cvs log: failed to create lock directory in repository '/develop/src/MAIN/vault/is/sap_intf_hq': Permission denied cvs log: failed to obtain dir lock in repository '/develop/src/MAIN/vault/is/sap_intf_hq' cvs [log aborted] : read lock failed - giving up How can I solve this? Thank you in advance. Sincerely, Irene Nicandro OMNI Services, Inc. Tel.#(540)-829-5518 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs problem
[EMAIL PROTECTED] writes: I am getting this problem: cvs log: failed to create lock directory in repository '/develop/src/MAIN/vault/is/sap_intf_hq': Permission denied Change the permissions on /develop/src/MAIN/vault/is/sap_intf_hq so that you're allowed to create files and directories there or set LockDir in your CVSROOT/config file to some other directory where you are permitted to create files and directories. -Larry Jones Shut up and go get me some antiseptic. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS problem
Hi, I have just set up a repository on a machine and I intend for all users to connect through the pserver. I have followed all of the instructions, and I can verify that all users can log in and log out of CVS. However, I get problems when I try to import code (although it does seem to work). The main problem is I cannot check out code. The error I get is cvs server: cannot open /root/.cvsignore: Permission denied cvs [server aborted]: can't chdir(/root): Permission denied after I try to do a checkout. It looks like an obvious permissions problem, but I can't see where. Does anybody know where I an going wrong? Thanks very much, David Churches. - David Churches Department of Physics and Astronomy Cardiff University, PO Box 913, Cardiff, CF2 3YB, U.K. Phone: + 44-29-20874785, 20875121 (direct line) Fax: + 44-29-20874056 [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS problem
Michal Wallace writes: short answer: put a -f after cvs in inetd.conf And if that isn't sufficient to fix the problem, upgrade to the current release of CVS (1.11.1p1) from www.cvshome.org. -Larry Jones If I get a bad grade, it'll be YOUR fault for not doing the work for me! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Wincvs and cvs problem after daylight savings time change??
Yes, the way Windows handles file dates is weird, but it's CVS that needs to
be fixed! The timestamp written to the entries file is supposedly UTC, for
any given 'real' time, this should be the same whether it is currently DST
or not, unfortunately such is not the case. Determining if a timestamp
falls within DST is fairly simple:
namespace {
bool btz;
TIME_ZONE_INFORMATION tz;
} // namespace anonymous
bool IsDaylightTime(unsigned __int64 timestamp)
{
if ( !btz ) {
btz = true;
GetTimeZoneInformation(tz);
}
CASSERT(sizeof(FILETIME) == sizeof(unsigned __int64));
SYSTEMTIME stStamp;
FileTimeToSystemTime((FILETIME*)timestamp, stStamp);
SYSTEMTIME lstStamp;
SystemTimeToTzSpecificLocalTime(tz, stStamp, lstStamp);
FILETIME ftStamp;
SystemTimeToFileTime(stStamp, ftStamp);
FILETIME lftStamp;
SystemTimeToFileTime(lstStamp, lftStamp);
unsigned __int64 utcstamp = *(unsigned __int64*)ftStamp;
unsigned __int64 localstamp = *(unsigned __int64*)lftStamp;
int minutes = (int)(__int64(utcstamp - localstamp) / 1000 / 60);
if ( minutes == tz.Bias + tz.DaylightBias )
return true;
return false;
}
I don't know how to go about getting the required changes integrated into
CVS though.
Jerry Nairn [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
There was a little discussion here, and a lot on the cvsgui mailing list
earlier this year, the last time we had a DST transition. The problem
arises
from the weird way Windows handles file dates, ...
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Wincvs and cvs problem after daylight savings time change??
From: Jonathan H Lundquist [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 30, 2001 4:10 PM Yes, the way Windows handles file dates is weird, but it's CVS that needs to be fixed! WinCVS (and cvsnt) had to be fixed because Windows is broken and will never be fixed. Full documentation is at: http://www.devguy.com/fp/cfgmgmt/cvs/#DST There is a better solution there than I mentioned in earlier mail, and this bit of background info in the brief FAQ: 3) Why does this problem exist? Because Microsoft's Win32 API file status reporting functions report incorrect file modification dates. According to Microsoft, This is by design. Thus, file status functions that work properly under Unix return incorrect results under Windows. Moreover, the incorrect results are incorrect in different ways depending on whether the file system is FAT or NTFS. Cheers, Jerry ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Wincvs and cvs problem after daylight savings time change??
There was a little discussion here, and a lot on the cvsgui mailing list earlier this year, the last time we had a DST transition. The problem arises from the weird way Windows handles file dates, but the solution for your workspace is simply to run cvs status from WinCVS. In WinCVS, you can right click on a folder, select Status selection from the menu, and it will correct the coloring of all files in that folder and its subfolders. Cheers, Jerry From: Michael Howes [mailto:[EMAIL PROTECTED]] Sent: Monday, October 29, 2001 5:05 PM I'm using the most recent version of cvs command line and wincvs 1.3.5.1 beta 5 any ideas who getting the time wrong and from where? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Wincvs and cvs problem after daylight savings time change??
In article 01nD7.2790$[EMAIL PROTECTED], Michael Howes wrote: I have a strange problem. I use BOTH the command line version of cvs and wincvs (I like some of the features in both). I've been using both for a while now just fine. What I often do is cvs update -d from the command line but do commits from wincvs. Afer the time change something is strange between the two (command line and wincvs). If I cvs update from the command line, then wincvs thinks ALL files are dirty (marking the icon red). This is a problem that happens somewhere in the date comparison. WinCVS uses the microsoft stat() function to retrieve the file timestamps from the filesystem. I suspect that stat() is doing a bogus adjustment for DST rather than retrieving universal values. I have an unconfirmed hypothesis that changing the routine to use some Win32 function to access the file time stamps could fix the problem. One way to reproduce the problem is simply to check out the files using WinCVS, and then flip your timezone setting. Such a flip should have no effect at all. -- . . . . . . - Mysterious Powdery Substance . ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Wincvs and cvs problem after daylight savings time change??
[EMAIL PROTECTED] wrote: Not sure if you're in the USA, but the 'mysterious powdery substance' tag line is unappreciated. May I politely suggest removing it, as hoaxes are being vigourously reported prosecuted. I would not hestitate for a second to allow the FBI to sort out your intentions by attaching such a tag line. -- John Minnihan mailto:[EMAIL PROTECTED] http://www.freepository.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs problem
Hi All, when I do a: cvs co src, where src is my source directory, I get the following errors and the co command fails : cvs checkout: Updating src cvs checkout: failed to create lock directory for '/data2/cvsroot/time/src' (/data2/cvsroot/time/src/#cvs.lock): Permission denied. cvs checkout: failed to obtain dir lock in repository '/data2/cvsroot/time/src' cvs [checkout aborted]: read lock failed - giving up If any of you have any idea whatthe problem is please mail me immediately. Thanks Sangeetha
Re: cvs problem
Sangeetha Parthasarathy writes: cvs checkout: Updating src cvs checkout: failed to create lock directory for '/data2/cvsroot/time/src' (/data2/cvsroot/time/src/#cvs.lock): Permission denied. cvs checkout: failed to obtain dir lock in repository '/data2/cvsroot/time/src' cvs [checkout aborted]: read lock failed - giving up You don't have permission to create a new subdirectory in /data2/cvsroot/time/src. Fix the permissions on that directory. -Larry Jones Another casualty of applied metaphysics. -- Hobbes ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS problem over Mandrake Linux
Matthew Riechers wrote: I start a Windows cvs client and try to connect as anonymous. The client return this message: CVS.EXE [login aborted]: could not find out home directory. I can not find where is the problem. Any ideas? Thanks in advance. Make sure $HOME is specified in your environment. More specifically, HOME should be specified in your client environment. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- He who laughs last thinks slowest. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS problem over Mandrake Linux
Hi all,
I will to use CVS over Mandrake as CVS Server.
I will to have password auth..
I configured my xinetd :
# /etc/cvs/cvs.conf.
service cvspserver
{
disable = no
port= 2401
socket_type = stream
protocol= tcp
wait= no
user= root
server = /usr/sbin/cvspserver
server_args = -f --allow-root=/cvsrep/avto
}
My cvs.conf is:
# -*- shell-script -*-
#
# Configuration file for the Mandrake CVS-related scripts
#
# Locations of CVS repositories you want to export via pserver
CVS_REPOS=/cvsrep/avto
I start a Windows cvs client and try to connect as anonymous.
The client return this message:
CVS.EXE [login aborted]: could not find out home directory.
I can not find where is the problem.
Any ideas?
Thanks in advance.
_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS problem
On Thu, May 10, 2001 at 10:37:22AM +1200, Chris Cameron wrote: That was my first reaction as well. However IMHO this theory is incorrect. 1. I check out a file. 2. I build the .o file 3. I make changes to the file. 4. I realise I made a mistake in the changes, so I remove the file and do an update 5. make will now do an unnecessary rebuild of my .o file While unnecessary, (5) produces correct results. If there was another step in your recipe: 3b. make and if (4) preserved the file's timestamp, then (5) would not happen, and the results would be *in*correct. Only I can make decision as to whether the make needs to rebuild the .o file True. But at least CVS fails safe. Your way, it wouldn't. and the best way for me to make the decision is to manually remove the .o file if it needs rebuilding! Which you might well forget to do, and then spend a *long* time trying to find an I thought I fixed that! bug. Probably a lot longer than you would have spent waiting for the superfluous recompile. This rebuild could have knock on effects throughout the rest of the developers sandbox. Alas, true. Perhaps update could have a preserve-timestamp option, to let you tell the program to do this usually-unsafe thing on occasions when you're sure it's ok (something like make -t in intent, though pretty much opposite in what it actually does :-). But making this the default behaviour would, IMO, be an *extremely* bad idea. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS problem
From: Chris Cameron [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 08, 2001 10:42 PM The checkout gets the correct timestamnp on the file. The first update gives bar.cc a timestamp which corresponds to the time you issued the update command. The second update give bar.cc the timestamp of the original checkin time of bar.cc That's the way it's supposed to work, to interact properly with make. Jerry ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS problem
That was my first reaction as well. However IMHO this theory is incorrect. 1. I check out a file. 2. I build the .o file 3. I make changes to the file. 4. I realise I made a mistake in the changes, so I remove the file and do an update 5. make will now do an unnecessary rebuild of my .o file Only I can make decision as to whether the make needs to rebuild the .o file and the best way for me to make the decision is to manually remove the .o file if it needs rebuilding! This rebuild could have knock on effects throughout the rest of the developers sandbox. *** Chris Cameron Open Telecommunications Ltd Product Manager IN Product Management [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jerry Nairn Sent: Thursday, 10 May 2001 5:50 a.m. To: 'Chris Cameron'; Infocvs Subject: RE: CVS problem From: Chris Cameron [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 08, 2001 10:42 PM The checkout gets the correct timestamnp on the file. The first update gives bar.cc a timestamp which corresponds to the time you issued the update command. The second update give bar.cc the timestamp of the original checkin time of bar.cc That's the way it's supposed to work, to interact properly with make. Jerry ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
FW: CVS problem
Greetings, One of our developers has reported the following behaviour from CVS. I think I've found in the update code where this behaviour, the question is whether there is a reason for this behaviour? Our developer expected the timestamp to revert to the original co timestamp. % cvs co foo/bar.cc % cd foo % ls -l % rm bar.cc % cvs update bar.cc % ls -l % rm bar.cc % vi CVS/Entries (remove the line for bar.cc) % cvs update bar.cc % ls -l The checkout gets the correct timestamnp on the file. The first update gives bar.cc a timestamp which corresponds to the time you issued the update command. The second update give bar.cc the timestamp of the original checkin time of bar.cc *** Chris Cameron Open Telecommunications Ltd Product Manager IN Product Management [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS problem
Dear Sir, Thanks for reply. According to your instruction i have done all the things but didn't succeed. following i have added in the inetd.conf 2401 stream tcp nowait root /usr/bin/cvs cvs -f --allow-root=/repository pserver when i restart the machine after adding this line to inetd.conf or Killall -HUP inetd.conf following are the error i got in /var/log/messages Apr 28 14:12:40 REDHAT inetd[469]: Bad config for pserver: Incomplete config entry (skipped) Apr 28 14:38:28 REDHAT inet: inetd shutdown succeeded Apr 28 14:38:28 REDHAT inetd[1050]: Bad config for pserver: Incomplete config entry (skipped) Apr 28 14:38:28 REDHAT inet: inetd startup succeeded Apr 28 14:38:39 REDHAT inet: inetd shutdown succeeded Apr 28 14:38:39 REDHAT inetd[1213]: Bad config for pserver: Incomplete config entry (skipped) Apr 28 14:38:39 REDHAT inet: inetd startup succeeded Apr 28 14:44:32 REDHAT inetd[1213]: cvspserver/tcp: bind: Address already in use Apr 28 14:44:32 REDHAT inetd[1213]: Bad config for --allow-root=/repository: Incomplete config entry (skipped) Apr 28 14:59:00 REDHAT inetd[1213]: 2401/tcp: bind: Address already in use Apr 28 14:59:00 REDHAT inetd[1213]: Bad config for --allow-root=/repository: Incomplete config entry (skipped) Apr 28 14:59:59 REDHAT inetd[1213]: Bad config for --allow-root=/root/repository: Incomplete config entry (skipped) I am using redhat 6.2 and CVS 1.10.7 please help me out in this problem With best regards, Sachin Desai Network/System Administrator. PopNet InfoTech India Pvt. Ltd E-mail: [EMAIL PROTECTED] Tel: +91 265 324 018 / 19 Fax: +91 265 334156 URL: www.popnet.co.in ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS problem
sachin desai writes: 2401 stream tcp nowait root /usr/bin/cvs cvs -f --allow-root=/repository pserver Most systems don't allow numeric port numbers in inetd.conf -- you probably need to add a cvspserver entry to your /etc/services file and use cvspserver instead of 2401 in inetd.conf. following are the error i got in /var/log/messages The error messages imply that you tried a number of different configurations which makes it somewhat difficult to discern which error messages pertain to the above configuration and which do not. In general, however, it looks like the inetd.conf entry is not all on one line like it needs to be -- perhaps your editor is automatically inserting line breaks for you. I am using redhat 6.2 and CVS 1.10.7 I would also suggest upgrading to the current release of CVS (1.11.1p1, or at least 1.11), which you can get from www.cvshome.org. -Larry Jones Oh, now YOU'RE going to start in on me TOO, huh? -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS problem
On Wed, May 02, 2001 at 03:18:22PM +0530, sachin desai wrote: Thanks for reply. According to your instruction i have done all the things but didn't succeed. following i have added in the inetd.conf 2401 stream tcp nowait root /usr/bin/cvs cvs -f --allow-root=/repository pserver Make sure that this is one line only! Regards, Matthias -- Matthias Kranz [EMAIL PROTECTED] http://www.belug.org/~kranz ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Problem
check your server logs. you probably didn't have '-f' in your inetd.conf line for cvs. sachin wrote: Dear Sir, From last three weeks i am tried to configure CVS in Red Hat 6.2 server with Wincvs client 1.2. I am facing same problem last three weeks. i could not solve the proble with help of manuals and CVS news group. the problem is as follows. NEW CVSROOT: :pserver:sachin@cvs:/usr/local/cvs (password authentication) cvs login (Logging in to sachin@cvs) cvs [login aborted]: recv() from server cvs: Connection reset by peer *CVS exited normally with code 1* can you help me out in this topic sachin -- === David Fuller Software Engineer TechSight, a business unit of GDDS phone: (413) 494 - 7538 [EMAIL PROTECTED] === ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Problem
sachin writes: cvs [login aborted]: recv() from server cvs: Connection reset by peer There's something wrong with your inetd.conf (or equivalent) -- inetd is listening for connections, but is unable to start the CVS server. Most likely, you have the path wrong in inetd.conf. You should also check your syslog for error messages from inetd. -Larry Jones Wow, how existential can you get? -- Hobbes ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS Problem
Dear Sir, From last three weeks i am tried to configure CVS in Red Hat 6.2 server with Wincvs client 1.2. I am facing same problem last three weeks. i could not solve the proble with help of manuals and CVS news group. the problem is as follows. NEW CVSROOT: :pserver:sachin@cvs:/usr/local/cvs (password authentication) cvs login (Logging in to sachin@cvs) cvs [login aborted]: recv() from server cvs: Connection reset by peer *CVS exited normally with code 1* can you help me out in this topic sachin
interesting CVS problem
Here's a scenario I ran into this weekend, wondering what the proper way to handle it would have been. (I know what I did was horrendous) 1. A user had checked in a bunch of images without -kb, and thus the images were corrupted when I tried to view them after checking them back out. 2. I told the user to delete the images from his working directory, then use cvs remove to remove all of them, and then commit. Then, add back in clean versions and commit again. 3. User did this, and instead of being added as new files, they were coming up as modified files (as if they weren't really deleted.) (Did he need to delete entire working directory and recheck out?) User was using WinCVS, not sure if this was a factor. 4. I then checked out the project (images included) and 'rm *.gif' followed by a cvs remove filename.gif for all files (by the way, is there an easier way to remove 20+ files than having to rm them from the filesystem first and then enter all the individual filenames on a cvs remove command?!) 5. While I was 'cvs remove'ing files, I got a conflict, saying that 'another user has modified deleted file foo.gif. Conflict created. Please resolve...yada...yada". Only, foo.gif was no longer in my working directory. I would do a cvs update foo.gif and it would say "conflict...please resolve..." but still no foo.gif reappeared in my working directory. So I had no way to even attempt to resolve the conflict. (which would have been impossible on a binary file anyway, but it brought up the general issue of "if I rm a file and then try to 'cvs remove' the file and another user has modified it, why can't i get it back to resolve conflicts and then finish removing it?) 4. Pressed for time, I then went into the actual repository and deleted all of the ,v files for the images. 5. Had user checkout the project. Naturally, he got an empty images directory, added all of the images back in, and all was hunky dory. 6. I thought this would then cause other users problems since potentially they'd still have the old images and the versions in the repository mgiht be lower than the versions in their working directories, but I think the images were all at initial revision and had never been modified at the time of deletion so this ended up not being an issue I think. So my question is, how *should* I have handled this? I also will gladly accept any and all razzing about the way I abused CVS. =) Thanks, Fran ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: interesting CVS problem
Fran Fabrizio writes: 1. A user had checked in a bunch of images without -kb, and thus the images were corrupted when I tried to view them after checking them back out. 2. I told the user to delete the images from his working directory, then use cvs remove to remove all of them, and then commit. Then, add back in clean versions and commit again. This was unnecessary. What you should have done was to have the user do ``cvs admin -kb'' on those files to mark them as binary in the repository, do ``cvs update'' in their working directory to pick up the binary flag, copy clean version into the working directory over top of the corrupt ones, and commit. 4. I then checked out the project (images included) and 'rm *.gif' followed by a cvs remove filename.gif for all files (by the way, is there an easier way to remove 20+ files than having to rm them from the filesystem first and then enter all the individual filenames on a cvs remove command?!) Yes -- "cvs rm -f". 5. While I was 'cvs remove'ing files, I got a conflict, saying that 'another user has modified deleted file foo.gif. Conflict created. Please resolve...yada...yada". Only, foo.gif was no longer in my working directory. I would do a cvs update foo.gif and it would say "conflict...please resolve..." but still no foo.gif reappeared in my working directory. So I had no way to even attempt to resolve the conflict. (which would have been impossible on a binary file anyway, but it brought up the general issue of "if I rm a file and then try to 'cvs remove' the file and another user has modified it, why can't i get it back to resolve conflicts and then finish removing it?) You just need to use "cvs add" to resurrect the deleted file. -Larry Jones I obey the letter of the law, if not the spirit. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs problem while every issue of command
hi i am using redhatlinux 7.0 with cvs version cvs-1.10.8-8 i have writtern down the procedure which i have done now I STARTED AS FOLLOWS. logged in as root * pwd /projects #mkdir project1 #cvs -d /projects/project1 init #chown -R sudhi project1 #chown -R mp3 project1 where mp3 contains users sudhi basavaraj sunil #cp /etc/shadow /projects/project1/CVSROOT/ then renamed the shadow file to passwd with only two fields in the entry then included in the /root/cvs_start file the line as --allow-root=/projects/project1 then restarted the daemon /etc/rc .d/init.d/xinetd restart which takes care of starting the daemon for cvspserver. 2nd stage; logged in as sudhi changed the CVSROOT in .bash_profile to CVSROOT=:pserver:sudhi@ganga:/projects/project1 export CVSROOT then logged in as sudhi again cvs login given the passwd. now if i went to import the module to the repository it imported into repository but it gaven an error saying that cvs server:cannot open/root/.cvsignore: permission denied cvs [server aborted]:cannot chdir(/root): permission deined and it exits. but the files will have been added to the repositiory. but when i checkout the same module i get the same error cvs server:cannot open/root/.cvsignore: permission denied cvs [server aborted]:cannot chdir(/root): permission deined but it creates a directory by that module but without any files and only CVS DIRECTORY under that. the above mentioned error is coming for all the users irrespective of the group and access limits. please help me in this regard. thanking you sudarshan ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs problem while every issue of command
Sudarshan writes: cvs server:cannot open/root/.cvsignore: permission denied cvs [server aborted]:cannot chdir(/root): permission deined Congratulations -- you're now the third person in three days to ask this question. See the manual: http://www.cvshome.org/docs/manual/cvs_21.html#SEC182 See the mailing list archives if you need more detailed help. -Larry Jones They can make me do it, but they can't make me do it with dignity. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: please help, cvs problem
Please, try to give the permissions 755 to the directory root.
On Wed, 24 Jan 2001, Patrick Amirian wrote:
Hi and thanks for reading,
I'm trying to set up a cvs repository,
this is how I'm doing it,
create the directory /home/patrick/cvsroot
then I do
cvs -d /home/patrick/cvsroot init
then I create my xinetd.conf file oh by the way I'm on RH 7.0
service cvspserver
{
socket_type = stream
protocol= tcp
wait= no
user= root
passenv =
server = /usr/bin/cvs
server_args = --allow-root=/home/pamirian/cvsroot pserver
}
and then I create a passwd file in /home/patrick/cvsroot/CVSROOT directory
when I do
cvs -d :pserver:patrick@matrix:/home/patrick/cvsroot login
it asks for the pass, I type the pass and it works great
BUT,
when I do
cvs -d :pserver:patrick@matrix:/home/patrick/cvsroot import -m "first
test" test patrick start
it also works but at first it gives me this message,
cvs server: cannot open /root/.cvsignore: Permission denied.
then when I do a
cvs -d :pserver:patrick@matrix:/home/patrick/cvsroot checkout test
it gives me,
cvs server: cannot open /root/.cvsignore : Permission denied
cvs [server aborted]: can't chdir (/root): Permission denied
how can I fix this ?
please don't point me at howtos, I already have 2 cvs books and few cvs
related documents but they don't cover this errors...
thank you very much for you time, I really appreciate it.
-Patrick
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: please help, cvs problem
Patrick Amirian writes: server_args = --allow-root=/home/pamirian/cvsroot pserver cvs server: cannot open /root/.cvsignore : Permission denied cvs [server aborted]: can't chdir (/root): Permission denied You need to add -f to the server_args, just like it says in the manual (http://www.cvshome.org/docs/manual/cvs_21.html#SEC182 near the end of the section). If that doesn't fix the problem, see the manual and the archives of this list (http://mail.gnu.org/pipermail/info-cvs/) for more help; this is a *very* frequently asked question. -Larry Jones In short, open revolt and exile is the only hope for change? -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: please help, cvs problem
In the archives of the info-cvs list is an email from [EMAIL PROTECTED]
describing how to set this up, and there's a reply from
[EMAIL PROTECTED] with an additional suggestion.
Use something like this:
service cvspserver
{
socket_type = stream
wait= no
user= root
env = HOME=/home/pamirian/cvsroot
server = /usr/bin/cvs
server_args = -f --allow-root=/home/pamirian/cvsroot pserver
}
From: Patrick Amirian [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 24, 2001 9:39 PM
my fault, consider pamirian being patrick
there is no problem with my directories... I'm not sure but
it seems to
be some kind of a permission problem when it's trying to access the
/root/.cvsignore file ... why root tho ? is it because cvs is
running as
root ?
Partly, but mainly because if HOME is set, cvs tries to read ${HOME}/.cvsrc
immediately when it starts, unless you run "cvs -f "
Cheers,
Jerry
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
please help, cvs problem
Hi and thanks for reading,
I'm trying to set up a cvs repository,
this is how I'm doing it,
create the directory /home/patrick/cvsroot
then I do
cvs -d /home/patrick/cvsroot init
then I create my xinetd.conf file oh by the way I'm on RH 7.0
service cvspserver
{
socket_type = stream
protocol= tcp
wait= no
user= root
passenv =
server = /usr/bin/cvs
server_args = --allow-root=/home/pamirian/cvsroot pserver
}
and then I create a passwd file in /home/patrick/cvsroot/CVSROOT directory
when I do
cvs -d :pserver:patrick@matrix:/home/patrick/cvsroot login
it asks for the pass, I type the pass and it works great
BUT,
when I do
cvs -d :pserver:patrick@matrix:/home/patrick/cvsroot import -m "first
test" test patrick start
it also works but at first it gives me this message,
cvs server: cannot open /root/.cvsignore: Permission denied.
then when I do a
cvs -d :pserver:patrick@matrix:/home/patrick/cvsroot checkout test
it gives me,
cvs server: cannot open /root/.cvsignore : Permission denied
cvs [server aborted]: can't chdir (/root): Permission denied
how can I fix this ?
please don't point me at howtos, I already have 2 cvs books and few cvs
related documents but they don't cover this errors...
thank you very much for you time, I really appreciate it.
-Patrick
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: please help, cvs problem
You have the allow-root set to /home/pamarian, but did a cvs init on
/home/patrick. That's the problem.
Patrick Amirian wrote:
Hi and thanks for reading,
I'm trying to set up a cvs repository,
this is how I'm doing it,
create the directory /home/patrick/cvsroot
then I do
cvs -d /home/patrick/cvsroot init
then I create my xinetd.conf file oh by the way I'm on RH 7.0
service cvspserver
{
socket_type = stream
protocol= tcp
wait= no
user= root
passenv =
server = /usr/bin/cvs
server_args = --allow-root=/home/pamirian/cvsroot pserver
}
and then I create a passwd file in /home/patrick/cvsroot/CVSROOT directory
when I do
cvs -d :pserver:patrick@matrix:/home/patrick/cvsroot login
it asks for the pass, I type the pass and it works great
BUT,
when I do
cvs -d :pserver:patrick@matrix:/home/patrick/cvsroot import -m "first
test" test patrick start
it also works but at first it gives me this message,
cvs server: cannot open /root/.cvsignore: Permission denied.
then when I do a
cvs -d :pserver:patrick@matrix:/home/patrick/cvsroot checkout test
it gives me,
cvs server: cannot open /root/.cvsignore : Permission denied
cvs [server aborted]: can't chdir (/root): Permission denied
how can I fix this ?
please don't point me at howtos, I already have 2 cvs books and few cvs
related documents but they don't cover this errors...
thank you very much for you time, I really appreciate it.
-Patrick
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: please help, cvs problem
my fault, consider pamirian being patrick
there is no problem with my directories... I'm not sure but it seems to
be some kind of a permission problem when it's trying to access the
/root/.cvsignore file ... why root tho ? is it because cvs is running as
root ?
Michael Peck wrote:
You have the allow-root set to /home/pamarian, but did a cvs init on
/home/patrick. That's the problem.
Patrick Amirian wrote:
Hi and thanks for reading,
I'm trying to set up a cvs repository,
this is how I'm doing it,
create the directory /home/patrick/cvsroot
then I do
cvs -d /home/patrick/cvsroot init
then I create my xinetd.conf file oh by the way I'm on RH 7.0
service cvspserver
{
socket_type = stream
protocol= tcp
wait= no
user= root
passenv =
server = /usr/bin/cvs
server_args = --allow-root=/home/pamirian/cvsroot pserver
}
and then I create a passwd file in /home/patrick/cvsroot/CVSROOT directory
when I do
cvs -d :pserver:patrick@matrix:/home/patrick/cvsroot login
it asks for the pass, I type the pass and it works great
BUT,
when I do
cvs -d :pserver:patrick@matrix:/home/patrick/cvsroot import -m "first
test" test patrick start
it also works but at first it gives me this message,
cvs server: cannot open /root/.cvsignore: Permission denied.
then when I do a
cvs -d :pserver:patrick@matrix:/home/patrick/cvsroot checkout test
it gives me,
cvs server: cannot open /root/.cvsignore : Permission denied
cvs [server aborted]: can't chdir (/root): Permission denied
how can I fix this ?
please don't point me at howtos, I already have 2 cvs books and few cvs
related documents but they don't cover this errors...
thank you very much for you time, I really appreciate it.
-Patrick
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS Problem
Your CVS may not be talking to the repository that you think it is contacting. Look on your machine's CVS directory and inspect the file called Root; it holds the $CVSROOT specification. Is this CVSROOT pointing to your repository? ...Ru -Original Message- From: Catherine Curtiss [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 04, 2001 10:07 AM To: [EMAIL PROTECTED] Subject: CVS Problem I'm having trouble using CVS. I will check out files, edit them, and commit them. It gives them a new version number (no error comes up), but the files are not updated. If I go to the CVS repository and look at the file there, it's the old version not the one I just modified. Has anyone seen this before? Thanks, Cathy ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Problem
You Wrote: I'm having trouble using CVS. I will check out files, edit them, and commit them. It gives them a new version number (no error comes up), but the files are not updated. If I go to the CVS repository and look at the file there, it's the old version not the one I just modified. Has anyone seen this before? Your respository (with the exception of the CVSROOT control directory) should only contain version control files (files that end with ,v). If you are looking in the repository and seeing normal files only, then you are not looking in the respostory. If you are seeing both version controlled files and normal files, then either someone has checked out the repository on top of itself, or someone has copied the normal files on top of the repository structure, and neither of these things were a good idea. Rex. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Problem
Catherine Curtiss writes: I'm having trouble using CVS. I will check out files, edit them, and commit them. It gives them a new version number (no error comes up), but the files are not updated. If I go to the CVS repository and look at the file there, it's the old version not the one I just modified. Has anyone seen this before? The files in the repository should all be RCS files -- the names should all end with ,v -- that contain all sorts of metadata and don't look anything like your checked out files. It sounds like you have some ordinary files in the repository that don't belong there that you're looking at instead. -Larry Jones The game's called on account of sudden death. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
[Info-cvs] Problem detected with missing files
We are in the process of converting over our repository from :local: on Windows NT to :pserver: on Linux. The repository was copied over and we wrote a script to modify each person's existing work area to point to the repository on the Linux server. This script changes the CVS/Root file in each directory. Pretty simple script. Everything worked fine except for one small problem. If you remove a file, then cvs update to get it back, an error message is generated: - cvs status Makefile === File: Makefile Status: Up-to-date Working revision:1.136.48.11 Repository revision: 1.136.48.11 /cvs/isis700/sw/Makefile,v Sticky Tag: Beta-Work-0 (branch: 1.136.48) Sticky Date: (none) Sticky Options: (none) - rm Makefile rm: remove `Makefile', overriding mode 0444? y - cvs update Makefile cvs [update aborted]: cannot find Makefile: No such file or directory Any clues? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs - problem
I normally try to check all the boards Before I ask for help. But I cant find this data. I had a person that was going through files to check for the passwd for a different system. when he was done I got this problem on CVS. Error: $cvstreedefault points to a repository not defined in %CVSROOT then it tells me to edit cvsweb.conf I would appreciate anyhelp anyone can give. Thanx. Scott Hulett [EMAIL PROTECTED]
Re: cvs - problem
Error: $cvstreedefault points to a repository not defined in %CVSROOT
then it tells me to edit cvsweb.conf
Scott,
This is an error message from cvsweb, not CVS. It indicates that cvsweb
is improperly configured. Someone should edit cvsweb.conf (If you don't
know where that is, grep your cvsweb.cgi script for the string '$config
=') and make sure the $cvstreedefault setting is pointing to one of the
entries in the %CVSROOT list. Here's an example from my system:
$ grep '$config =' cvsweb.cgi
$config = $ENV{'CVSWEB_CONFIG'} || '/home/cvsweb/Current/cvsweb.conf';
$ vi cvsweb.conf
...
##
# CVS Root
##
# CVSweb can handle several CVS-Repositories
# at once. Enter a short symbolic names and the
# full path of these repositories here.
# NOTE that the symbolic names may not contain
# whitespaces.
# Note, that cvsweb.cgi currently needs to have physical access
# to the CVS repository so :pserver:[EMAIL PROTECTED]:/data/cvsroot
# won't work!
# 'symbolic_name' 'path_to_the_actual_repository'
%CVSROOT = (
'Sputnik7_Main_CVS_Repository' = '/home/cvs/cvsrep',
## 'Sputnik7_Alternate_CVS_Repository' =
'/home/cvs/cvsrep2',
);
# This tree is enabled by default when
# you enter the page
$cvstreedefault = 'Sputnik7_Main_CVS_Repository';
= Avi Green :) (: www.sputnik7.com =
Unix S/A System Specialist
avi at sputnik7.com 212 217-1147
CVS problem on windows NT
Hi, I have some problems to run CVS on Windows NT. I would like to createa multiple developpers project with CVS on NT. I put a project on my machine and I would like that a person can access to this project fromits machine. To do that I execute this command from the "client" machine: cvs -d :ext:denis@stage4 : d:\projet_constantin\cvs checkout CO1 denis:user name which can access to the project stage4 :the name of the machine where the project is stored d:\projet_constantin : corresponds to the CVSROOT value CO1 : project module name. Is this command correct ? Is it necessary to install a CVS server to do that ? Where canI find CVS documentation for NT? Thanks a lot.
RE: CVS problem on windows NT
Hi, try the following links, but be warned, CVS on NT is a bit messy http://www.wincvs.org/ http://www.wincvs.org/ http://betty.magenta-logic.com/cvs/ http://betty.magenta-logic.com/cvs/ and links therein good luck Jürgen Eitle Voice : +41 22 909-7123 ELCA Informatique SAFax : +41 22 909-7100 rue Rothschild 50e-m: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 1202 Geneva Switzerland
RE: CVS problem on windows NT
There is a seperate mailing list for CVS NT, get the latest cvs for nt, and mailing list info from: http://www.cvsnt.com/ Regs, Arthur -Original Message- From: Denis Trompette [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, May 23, 2000 11:33 PM To: [EMAIL PROTECTED] Subject: CVS problem on windows NT Hi, I have some problems to run CVS on Windows NT. I would like to create a multiple developpers project with CVS on NT. I put a project on my machine and I would like that a person can access to this project from its machine. To do that I execute this command from the "client" machine: cvs -d :ext:denis@stage4 : d:\projet_constantin\cvs checkout CO1 denis : user name which can access to the project stage4 : the name of the machine where the project is stored d:\projet_constantin :corresponds to the CVSROOT value CO1 : project module name. Is this command correct ? Is it necessary to install a CVS server to do that ? Where can I find CVS documentation for NT? Thanks a lot.
Re: CVS problem
[EMAIL PROTECTED] on 05/14/2000 05:39:09 PM Chris Cowan [EMAIL PROTECTED] writes: In the past (no longer), I've used or attempted to used RCS and CVS with both AFS and DFS. (I admined AFS for over 6 years, DFS for 2 years). I would avoid the AFS/CVS combination for the following reasons: I've been using CVS with AFS for years now and it works great. It's a bit slower than having a repository on local disk, but ease of backups and universal accessibility more than makes up for it. I use client/server CVS. To get around the backup problems (since my workstation isn't backed up), I rsync my working directories over to the server that is backed up. On top of that, I also make local tarballs (since recovery from backup can be painful here). Bottom line, I would follow the advice of the other person that replied. Use CVS in client/server mode or use a remote filesystem that can handle the POSIX functionality upon which CVS depends, like DFS or NFS (w/ the lock manager). I couldn't disagree more strongly; that's horrible advice. CVS works great on AFS. I haven't used AFS at all so the following is a wild guess. Could problems occur in the way CVS creates repository locks? CVS assumes that creating a directory is an atomic operation. Therefore, if it's able to create a lock directory, it assumes noone else is able. Noel This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Co. Incorporated, its subsidiaries and affiliates.
Re: CVS problem
I don't understand. What would prevent you from using CVS in client/server mode To begin with, we can ignore pserver out of hand, right? (unless those that configured it absolutely turned it off) if you're able to use it in local mode? The only thing I can think of is if the repository is mounted and you don't have a login to the machine that it's mounted on. Yes, assuming you meant "the repository is mounted on a network filesystem from a fileserver, and you don't have an account on the fileserver." Exactly. Somewhere on the web you will find advice on creating reliable networked filesystems, which will say "First, don't let any ordinary users ever log into the fileserver." Users may have accounts, but the accounts exist purely for book-keeping and filesystem quota purposes. Users can neither log in nor ssh in nor ... do anything to a fileserver, except access files from in using the network filesystem. I think this is a fairly typical configuration. Certainly, it's been the rule at the 5 different sites I've worked in over the last 15 years. Assuming a default configuration. All one would have to do is set their CVSROOT properly, possibly set CVS_SERVER, and set CVS_RSH if one isn't using rsh. You could get away with this by running "cvs server" not on a fileserver, i.e. not on a local disk, but on a network filesystem client. I can even imagine that this might simplify things wrt filesystem coherency --- everyone running through a single cache manager --- even though I have never encountered problems in that area. But it doesn't always work, because of account administration. Consider the AFS example, first the world, and then inside a single company: The University of Wisconsin CS department uses AFS. It uses "public" AFS - all UW CS filesystems area available anywhere in the world that has an AFS client. If I want to work with somone at Rutgers, I only have to add him to the ACLs for my CVS repository, and he can pick it up over AFS. (This assumes that you are using cross-realm authentication.) Without AFS, I would have to give him an account on the machine that holds the repository so that he can run CVS server. Or, create an anonymous account, or, have him use my account, with some sort of additional layer of security or authentication. None of which I am allowed to do, or, at least, none of which I should be allowd to do on a properly secured system. (Wrt the only secure option, giving him an account, I may just not want the hassle of doing so.) Now consider a company that, say, has sites in Oregon, California, Israel, Arizona, and Washington. It has internal firewalls - firewalls not just between the intranet and the internet, but firewalls between the Israel and Oregon, and even between projects in Oregon. The company has already gone to the effort of setting up a corporate wide AFS, and arranging for it to cross the firewalls. I.e. the security of AFS is felt to be sufficient to make the security mavens happy. (One day DFS will be available on the platforms I want it on.) Other traffic across the firewalls is restricted: FTP, telnet, SSH. Now say I'm in Oregon and I want to work with someone in Israel. CVS pserver is out - the intra-company firewall doesn't allow it, and I do not believe that pserver is secure enough to ask. RSH out. SSH might be okay, but then I need to arrange for the Israeli to have an account in Oregon, or vice versa; i.e. I fall back to the account administration issue. All of this is extra hassle since AFS is already everywhere. (Now, I fudged a little bit - last I checked, cross realm authentication wasn't working properly in AFS. It may be necessary to obtain a remote account just so that you can obtain a token from the realm you want to access files in. Nevertheless, an account just to allow authentication is a hell of a lot less dangerous than an account that is actually authorized to do things remotely.)
Re: CVS problem
"What are you doing working at a company in a not officially supported role? Are you daft or stupid?!?". You must have a very uninteresting job, Toby, if all the work you do is officially supported. More than half of the work I do is skunkwork, unofficial, unsupported - and my bosses realize it, and thank me for it the maybe 25% of the time that my "extra" work turns out to be a good idea, and makes a few billion dollars. "Unofficial" just means that I don't have a budget for it, can't hire IT to allocate space on a server, etc. It must be very boring to just do what you're told.
Re: CVS problem
Michael, In the past (no longer), I've used or attempted to used RCS and CVS with both AFS and DFS. (I admined AFS for over 6 years, DFS for 2 years). I would avoid the AFS/CVS combination for the following reasons: - AFS (unlike DFS) does not support any sort file locking in the "normal" (POSIX) manner. Even if you enable the "k" ACL on the directory! - It is not trivial to properly set up AFS ACLs so that you get the correct permissions and access by all parties using the CVS repository. It may not be possible! - Many users of AFS get very confused by the difference between RO and RW volumes. Typically, this is done with mount points. This is usually differentiated by using /afs/.iil instead of /afs/ill.I would be absolutely sure that your CVS repository does not sit in any replicated volumes. If so, make sure you're accessing the RW copy. - The recursion you're seeing "smells" like a backup volume somewhere.Depending upon where the backup volume is mounted, this could cause some interesting problems. Some of what your seeing could be more effectively diagnosed by adding the global CVS option -v. Bottom line, I would follow the advice of the other person that replied. Use CVS in client/server mode or use a remote filesystem that can handle the POSIX functionality upon which CVS depends, like DFS or NFS (w/ the lock manager). Michael S. Tsirkin" wrote: Hello! I have encountered the following bug with cvs-1.10.7 Help/comments will be appreciated. Pls mail me at [EMAIL PROTECTED] Thanks, MST - Forwarded message from "Michael S. Tsirkin" [EMAIL PROTECTED] - Date: Sun, 14 May 2000 17:57:41 +0300 From: "Michael S. Tsirkin" [EMAIL PROTECTED] To: Michael Tsirkin [EMAIL PROTECTED] Subject: CVS problem Reply-To: "Michael S. Tsirkin" [EMAIL PROTECTED] Try this: we have cvsroot in /afs/iil/nike/data/fcde/cvsroot Further, under this we have directory pvpd_utils and under this src. I go ahead and check out pvpd_utils, in some directory: cvs -d /afs/iil/nike/data/fcde/cvsroot co pvpd_utils Now, I'm doing something weird: cvs -d /afs/iil/nike/data/fcde/cvsroot co pvpd_utils/src/.. This fails: cvs checkout: existing repository /afs/iil/nike/data/fcde/cvsroot/pvpd_utils does not match /afs/iil/nike/data/fcde/cvsroot/pvpd_utils/src/.. cvs checkout: ignoring module pvpd_utils/src/.. Now if I try some cvs operation, e.g. cvs co . it will go crazy: cvs checkout: Updating pvpd_utils/. cvs checkout: Updating pvpd_utils/./bin cvs checkout: Updating pvpd_utils/./doc cvs checkout: Updating pvpd_utils/./samples cvs checkout: Updating pvpd_utils/./setup cvs checkout: Updating pvpd_utils/./src cvs checkout: Updating pvpd_utils/./src/.. cvs checkout: Updating pvpd_utils/./src/../bin cvs checkout: Updating pvpd_utils/./src/../doc cvs checkout: Updating pvpd_utils/./src/../samples begin:vcard n:Cowan;Chris tel;cell:512-970-7294 tel;fax:707-988-8744 tel;work:512-329-5646 x1306 x-mozilla-html:FALSE url:http://www.2nd-wave.com org:2nd Wave, Inc. version:2.1 email;internet:[EMAIL PROTECTED] title:Development Manager adr;quoted-printable:;;1515 Capital of Texas Highway South=0D=0A=0D=0ASuite 400A;Austin;TX;78746; note;quoted-printable:Tivoli Certified Enterprise Consultant=0D=0A end:vcard
Re: CVS problem
Andy Glew [EMAIL PROTECTED] writes: From: Russ Allbery [EMAIL PROTECTED] I've been using CVS with AFS for years now and it works great. It's a bit slower than having a repository on local disk, but ease of backups and universal accessibility more than makes up for it. By the way: are you using AFS on LINUX with CVS? Mostly Solaris, but we also use Linux, HP-UX, AIX, Tru64, and IRIX. What release of the AFS client? Arla? Lots of versions of AFS from the unofficial contrib client based on 3.3 up to the current version of AFS 3.6. I've never used Arla; I know some people here who do with some success, but it's not as reliable. Do cvs co -P (prune) or cvs release -d work? Yup, although cvs release -d won't work if the top level directory you're trying to remove is a mount point (for somewhat obvious reasons. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: CVS problem
This is a slight detour, but I could not resist. On Sunday, May 14, "Andy Glew" wrote: (1) I see that you are using CVS and AFS. Many readers of this list recommend using CVS server mode, rather than upon a network filesystem. I must admit that I think that is bogus - else what's a network filesystem for? - but there you have it. IFF the network filesystem implemented the right filesystem semantics correctly, I'd agree with you. However, for efficiency reasons, I beg to differ. You meaning to tell me that running an Oracle DB in this sort of distributed fashion should work well? There are any number of reasons that CVS system should not use network distributed filesystems. The best I can think of, is to make the CVS "protocol" the defacto "standard" way of interoperating with CVS, thereby decoupling the repository from the client, enabling the possibilities of actually doing some further development and implementation of various features... (2) Are you, by any chance, using LINUX? Ahh, the anti-unix. :-) -- Notice the *smiley* people... I have been having problems left, right, and center with the combination of CVS, LINUX, and AFS. My sysadmins tell me that the LINUX AFS client has problems, doing things like returning incorrect status for directory queries. The beauty of blaming the wrong piece of software is that it is so convenient. I'm not 100% sure, but I thought that rcs/cvs specified the type of filesystem semantics they assumed to be working under/over/with. If these semantics are in error, in whichever way that may be, then you can't really expect cvs to its job correctly. I suspect that LINUX/AFS is also associated with broken timestamps, updates that don't really work, etc. "Suspect" because I haven't isolated the problem, but I have been having all sorts of issues since I started using CVS to do builds on LINUX. On LINUX, or LINUX/AFS? I have my own pet-peeve with how linux goes about ignoring various standards, and implements its own semantics with various system calls. However, this is not the forum to get into this. If it is LINUX/AFS you are having trouble with, then I would suggest using client-server, and if necessary, local filesystems on both ends (the server anyhow) to do your work in. (local filesystems tend to be faster to compile/work with anyhow). I am about to declare myself a personal rule: not to use CVS on AFS on LINUX, at least until a new rev of the AFS client for LINUX comes out. Only to use CVS on AFS on Solaris/x86. One place I worked for had CVS performance trouble. They were using it over NFS, client-server, and a number of other ways. After cleaning things up, going completely client-server, and using local disk for both the repo, and the client-side, they saw at *least* a 10-fold improvement. (Ok, there was a server upgrade in there as well...) My "rule" with CVS has always been: Use client-server, use local disk. --Toby.
Re: CVS problem
Russ Allbery wrote: Chris Cowan [EMAIL PROTECTED] writes: - AFS (unlike DFS) does not support any sort file locking in the "normal" (POSIX) manner. Even if you enable the "k" ACL on the directory! Irrelevant for CVS, which uses dot-locking that works fine in AFS. Well call me skeptical, but have you actually stressed this in a variety of situations or are you just basically working with a small group of well behaved developers (very little merging and conflicts), from your own machine (the one cache manager case)? Have you included cases where multiple users attempt to commit the same module, from different machines (and thus multiple cache managers)? I can visualize a number of scenarios where things may not go totally smoothly. (Suppose I lose Network connectivity during a commit? Do I have to get multiple people to flush cache managers in order to guarantee a successful commit?) Sorry, but I've been bitten by the non-POSIX filesystem semantics of AFS enough times in the past, that I would want to thoroughly test this. (or know that someone else had first.) - It is not trivial to properly set up AFS ACLs so that you get the correct permissions and access by all parties using the CVS repository. It may not be possible! It's trivial. Give everyone who needs to commit to a tree "write" access to all directories in that tree, give everyone "read" access to CVSROOT, and create a subdirectory of CVSROOT (I call it logs), give everyone "write" access to it, move the history and val-tags files into it, and symlink to the files. I disagree. It's trivial for an AFS admin, not necessarily a general user. - Many users of AFS get very confused by the difference between RO and RW volumes. Typically, this is done with mount points. This is usually differentiated by using /afs/.iil instead of /afs/ill. I would be absolutely sure that your CVS repository does not sit in any replicated volumes. If so, make sure you're accessing the RW copy. Don't replicate your CVS repository, other than the top-level mount point volume if you use that sort of scheme. You should in general never replicate development trees; replication is for mostly static data that needs to always be available. Well nowhere in the original post did the author identify himself as an AFS Admin or a general user. I assumed that he might be the later. If that's the case, the decision has been made for him. Bottom line, I would follow the advice of the other person that replied. Use CVS in client/server mode or use a remote filesystem that can handle the POSIX functionality upon which CVS depends, like DFS or NFS (w/ the lock manager). I couldn't disagree more strongly; that's horrible advice. CVS works great on AFS. I'm really recommending pserver. There it's unambiguous. Works as documented and intended, and I don't have to explain nearly as much to somebody else.I can use just about any old Wintel box for the task. Given the price of 20GB IDE drive these days, I find very little incentive for using any remote filesystem in this scenario. If I had AFS available, I would archive my repository to it via Cron. begin:vcard n:Cowan;Chris tel;cell:512-970-7294 tel;fax:707-988-8744 tel;work:512-329-5646 x1306 x-mozilla-html:FALSE url:http://www.2nd-wave.com org:2nd Wave, Inc. version:2.1 email;internet:[EMAIL PROTECTED] title:Development Manager adr;quoted-printable:;;1515 Capital of Texas Highway South=0D=0A=0D=0ASuite 400A;Austin;TX;78746; note;quoted-printable:Tivoli Certified Enterprise Consultant=0D=0A end:vcard
CVS problem
Hello! I have encountered the following bug with cvs-1.10.7 Help/comments will be appreciated. Pls mail me at [EMAIL PROTECTED] Thanks, MST - Forwarded message from "Michael S. Tsirkin" [EMAIL PROTECTED] - Date: Sun, 14 May 2000 17:57:41 +0300 From: "Michael S. Tsirkin" [EMAIL PROTECTED] To: Michael Tsirkin [EMAIL PROTECTED] Subject: CVS problem Reply-To: "Michael S. Tsirkin" [EMAIL PROTECTED] Try this: we have cvsroot in /afs/iil/nike/data/fcde/cvsroot Further, under this we have directory pvpd_utils and under this src. I go ahead and check out pvpd_utils, in some directory: cvs -d /afs/iil/nike/data/fcde/cvsroot co pvpd_utils Now, I'm doing something weird: cvs -d /afs/iil/nike/data/fcde/cvsroot co pvpd_utils/src/.. This fails: cvs checkout: existing repository /afs/iil/nike/data/fcde/cvsroot/pvpd_utils does not match /afs/iil/nike/data/fcde/cvsroot/pvpd_utils/src/.. cvs checkout: ignoring module pvpd_utils/src/.. Now if I try some cvs operation, e.g. cvs co . it will go crazy: cvs checkout: Updating pvpd_utils/. cvs checkout: Updating pvpd_utils/./bin cvs checkout: Updating pvpd_utils/./doc cvs checkout: Updating pvpd_utils/./samples cvs checkout: Updating pvpd_utils/./setup cvs checkout: Updating pvpd_utils/./src cvs checkout: Updating pvpd_utils/./src/.. cvs checkout: Updating pvpd_utils/./src/../bin cvs checkout: Updating pvpd_utils/./src/../doc cvs checkout: Updating pvpd_utils/./src/../samples cvs checkout: Updating pvpd_utils/./src/../setup cvs checkout: Updating pvpd_utils/./src/../src cvs checkout: Updating pvpd_utils/./src/../src/.. cvs checkout: Updating pvpd_utils/./src/../src/../bin cvs checkout: Updating pvpd_utils/./src/../src/../doc cvs checkout: Updating pvpd_utils/./src/../src/../samples cvs checkout: Updating pvpd_utils/./src/../src/../setup cvs checkout: Updating pvpd_utils/./src/../src/../src cvs checkout: Updating pvpd_utils/./src/../src/../src/.. cvs checkout: Updating pvpd_utils/./src/../src/../src/../bin cvs checkout: Updating pvpd_utils/./src/../src/../src/../doc cvs checkout: Updating pvpd_utils/./src/../src/../src/../samples cvs checkout: Updating pvpd_utils/./src/../src/../src/../setup cvs checkout: Updating pvpd_utils/./src/../src/../src/../src cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/.. cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../bin cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../doc cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../samples cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../setup cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/.. cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../bin cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../doc cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../samples cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../setup cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../src cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../src/.. cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../src/../bin cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../src/../doc cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../src/../samples cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../src/../setup cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../src/../src cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../src/../src/.. cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../src/../src/../bin cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../src/../src/../doc cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../src/../src/../samples cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../src/../src/../setup cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../src/../src/../src cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../src/../src/../src/.. cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../src/../src/../src/../bin cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../src/../src/../src/../doc cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../src/../src/../src/../samples cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../src/../src/../src/../setup cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../src/../src/../src/../src cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../src/../src/../src/../src/.. cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../src/../src/../src/../src/../bin cvs checkout: Updating pvpd_utils/./s
Re: CVS problem
One place I worked for had CVS performance trouble. They were using it over NFS, client-server, and a number of other ways. After cleaning things up, going completely client-server, and using local disk for both the repo, and the client-side, they saw at *least* a 10-fold improvement. (Ok, there was a server upgrade in there as well...) My "rule" with CVS has always been: Use client-server, use local disk. Unfortunately, I have never yet worked in a place where I was allowed to set up my own CVS server. Or, if I had control over my own machine, where my CVS server could network across the various intra-company gateways to all the places where I and others needed to access it. But, in that same company (which also happens to be the one Michael is working at) AFS went everywhere. Going client-server only will make CVS impossible to use for small, ad-hoc, users who are not officially supported by their companies. E.g. I use RCS for all of my personal files, .cshrc, etc. I was thinking of going to CVS, but if CVS is client server only, I will not be able to.
Re: CVS problem
One place I worked for had CVS performance trouble. They were using it over NFS, client-server, and a number of other ways. After cleaning things up, going completely client-server, and using local disk for both the repo, and the client-side, they saw at *least* a 10-fold improvement. (Ok, there was a server upgrade in there as well...) My "rule" with CVS has always been: Use client-server, use local disk. By the way, at the site that I am currently working (UWiscCS), just about all diskspace is AFS. Local disk is not backed up. Only AFS disks are backed up. It would be rather stupid to put a CVS repository on a local disk in such a situation. Now, one could run CVS server with a repository on an AFS filesystem that was never accessed remotely.
Re: CVS problem
I have no explicit diagnosis, but (1) I see that you are using CVS and AFS. Many readers of this list recommend using CVS server mode, rather than upon a network filesystem. I must admit that I think that is bogus - else what's a network filesystem for? - but there you have it. (2) Are you, by any chance, using LINUX? I have been having problems left, right, and center with the combination of CVS, LINUX, and AFS. My sysadmins tell me that the LINUX AFS client has problems, doing things like returning incorrect status for directory queries. I *know* that I cannot do a cvs co or cvs release on LINUX/AFS, and expect it to work reliably. Any directory manipulations by CVS using LINUX/AFS are suspect - certainly, "prune" and "release" don't work, but I suspect that making directories has issues. I suspect that LINUX/AFS is also associated with broken timestamps, updates that don't really work, etc. "Suspect" because I haven't isolated the problem, but I have been having all sorts of issues since I started using CVS to do builds on LINUX. I am about to declare myself a personal rule: not to use CVS on AFS on LINUX, at least until a new rev of the AFS client for LINUX comes out. Only to use CVS on AFS on Solaris/x86. - Original Message - From: Michael S. Tsirkin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 14, 2000 10:15 AM Subject: CVS problem Hello! I have encountered the following bug with cvs-1.10.7 Help/comments will be appreciated. Pls mail me at [EMAIL PROTECTED] Thanks, MST - Forwarded message from "Michael S. Tsirkin" [EMAIL PROTECTED] - Date: Sun, 14 May 2000 17:57:41 +0300 From: "Michael S. Tsirkin" [EMAIL PROTECTED] To: Michael Tsirkin [EMAIL PROTECTED] Subject: CVS problem Reply-To: "Michael S. Tsirkin" [EMAIL PROTECTED] Try this: we have cvsroot in /afs/iil/nike/data/fcde/cvsroot Further, under this we have directory pvpd_utils and under this src. I go ahead and check out pvpd_utils, in some directory: cvs -d /afs/iil/nike/data/fcde/cvsroot co pvpd_utils Now, I'm doing something weird: cvs -d /afs/iil/nike/data/fcde/cvsroot co pvpd_utils/src/.. This fails: cvs checkout: existing repository /afs/iil/nike/data/fcde/cvsroot/pvpd_utils does not match /afs/iil/nike/data/fcde/cvsroot/pvpd_utils/src/.. cvs checkout: ignoring module pvpd_utils/src/.. Now if I try some cvs operation, e.g. cvs co . it will go crazy: cvs checkout: Updating pvpd_utils/. cvs checkout: Updating pvpd_utils/./bin cvs checkout: Updating pvpd_utils/./doc cvs checkout: Updating pvpd_utils/./samples cvs checkout: Updating pvpd_utils/./setup cvs checkout: Updating pvpd_utils/./src cvs checkout: Updating pvpd_utils/./src/.. cvs checkout: Updating pvpd_utils/./src/../bin cvs checkout: Updating pvpd_utils/./src/../doc cvs checkout: Updating pvpd_utils/./src/../samples cvs checkout: Updating pvpd_utils/./src/../setup cvs checkout: Updating pvpd_utils/./src/../src cvs checkout: Updating pvpd_utils/./src/../src/.. cvs checkout: Updating pvpd_utils/./src/../src/../bin cvs checkout: Updating pvpd_utils/./src/../src/../doc cvs checkout: Updating pvpd_utils/./src/../src/../samples cvs checkout: Updating pvpd_utils/./src/../src/../setup cvs checkout: Updating pvpd_utils/./src/../src/../src cvs checkout: Updating pvpd_utils/./src/../src/../src/.. cvs checkout: Updating pvpd_utils/./src/../src/../src/../bin cvs checkout: Updating pvpd_utils/./src/../src/../src/../doc cvs checkout: Updating pvpd_utils/./src/../src/../src/../samples cvs checkout: Updating pvpd_utils/./src/../src/../src/../setup cvs checkout: Updating pvpd_utils/./src/../src/../src/../src cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/.. cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../bin cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../doc cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../samples cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../setup cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/.. cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../bin cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../doc cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../samples cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../setup cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../src cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../src/.. cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../src/../bin cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../src/../doc cvs checkout: Updating pvpd_utils/./src/../src/../src/../src/../src/../src/../samples cvs checkout: Updating pvpd_
Re: CVS problem
Chris Cowan [EMAIL PROTECTED] writes: Russ Allbery wrote: Irrelevant for CVS, which uses dot-locking that works fine in AFS. Well call me skeptical, but have you actually stressed this in a variety of situations or are you just basically working with a small group of well behaved developers (very little merging and conflicts), from your own machine (the one cache manager case)? We have a small, fairly well-behaved group of developers. We do do branches and merges, mostly merges from vendor branches but occasionally other kinds, and we definitely all work from different machines and don't use the same cache manager. It's also used for courses here, which often have a lot heavier usage and more frequent conflicts and the like (student programmers often aren't well-behaved). I've never heard of problems. Regardless of that, though, POSIX locking has absolutely nothing to do with CVS. It simply doesn't. CVS doesn't use it, or at least doesn't need to use it. It uses a variety of dot-locking in the lock directories, when set up that way (which you certainly should for AFS), and that works just fine with AFS. Have you included cases where multiple users attempt to commit the same module, from different machines (and thus multiple cache managers)? Yes, we have done this. I can visualize a number of scenarios where things may not go totally smoothly. (Suppose I lose Network connectivity during a commit? Do I have to get multiple people to flush cache managers in order to guarantee a successful commit?) No, because this is why CVS locks. This is the whole point of locking, and AFS does not rely on POSIX file locking. Sorry, but I've been bitten by the non-POSIX filesystem semantics of AFS enough times in the past, that I would want to thoroughly test this. You haven't been bitten by POSIX file locking with CVS because CVS doesn't use it. AFS commits file creations immediately under most circumstances, which is what CVS needs. I disagree. It's trivial for an AFS admin, not necessarily a general user. The AFS admin can make instructions that will be trivial for someone else to follow; I've done some of this before. I'd consider it part of the job of an AFS admin. It's trivial once you understand AFS directory ACLs, which is the hard part. For a simple, one-project repository, just give everyone write access to the whole repository and it works fine. The more complicated setup is only needed if you want to limit who can modify CVSROOT. I'm really recommending pserver. I would never recommend pserver to anyone, even someone who *has* to use client/server or has to support anonymous repository access. I really think this is bad advice in most circumstances, although I'm sure it does work for some people. I consider pserver to inherently be a security risk, not to mention difficult and complicated to set up in a fashion that provides any security guarantees. Client/server works great over either ssh or Kerberized rsh, both of which I've used with quite a bit of success. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
CVS Problem: limit on number of CVS repositories
Hello, Here a description of the problem: The file /etc/inetd.conf needs to be edited so inetd knows to run the command 'cvs pserver' when it receives a connection on the right port. By default, the port number is 2401. The '--allow-root' option specifies the allowable CVSROOT directory. If there is more than one CVSROOT directory, the option must be repeated. For each (new) repository the corresponding CVSROOT directory must be entered as an '--allow-root' option in the 'inetd.conf' file!! (otherwise a connection will not be allowed). Since no more than five arguments are allowed in the field (in inetd.conf) specifying the portlistener command, this limits the maximum number of (distinct) repositories to three(3) (cvs and pserver already count for two!). Is there a work-around (better: a solution!) for this problem? In other words: How can we make inetd work with more than three repositories. P.S. We need the inetd configuration to use, within CVS, the pserver functionality, which in turn is necessary in order to use WinCVS as a Windows Client to the CVS repository. Thanks for your help, Guido Duerinckx Björn Quirynen
Re: CVS Problem: limit on number of CVS repositories
[EMAIL PROTECTED] writes: Since no more than five arguments are allowed in the field (in inetd.conf) specifying the portlistener command, this limits the maximum number of (distinct) repositories to three(3) (cvs and pserver already count for two!). The current version of the Cederqvist manual mentions this (potential -- only some version of inetd have this limit) problem and suggests having inetd run a shell script that then calls cvs with the appropriate arguments as the usual solution. -Larry Jones It's not denial. I'm just very selective about the reality I accept. -- Calvin
Re: CVS Problem: limit on number of CVS repositories
In message [EMAIL PROTECTED], Guido.Duerinckx@alca tel.be writes: Hello, Here a description of the problem: The file /etc/inetd.conf needs to be edited so inetd knows to run the command 'cvs pserver' when it receives a connection on the right port. By default, the port number is 2401. The '--allow-root' option specifies the allowable CVSROOT directory. If there is more than one CVSROOT directory, the option must be repeated. Hi, There are two solutions: 1) (from deep in the info files) is write a wrapper script around cvs, and have inetd call the wrapper script. 2) Apply the patch that I wrote that adds an option to list the cvs trees in a file. The patch is still unofficial, but I was hoping to get it commited to the main cvs tree. The option is --allow-root-list, and the patch is at http://www.cs.umd.edu/~capveg/cvs.root-allow-list.patch . [ It would seem that my web directory got blown away by FrontPage!$*^$$, I will restore the patch promptly, but if you get a 404 on it, try again in a few hours or mail me. Sorry] If you decided to go with #2, please let me know if you run into any problems. - Rob .
