[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: cvs not ignoring permissions
From: |
Paul Shields |
Subject: |
RE: cvs not ignoring permissions |
Date: |
Wed, 30 Jul 2003 16:56:34 -0400 |
Yes that is the problem I am reporting. However now that I look at it,
it seems dependent on keywords. Here are the commands that duplicate
the problem.
$ umask
0002
$ ls -al configure.sh
-rw-rw-r-- 1 pauls pauls 1506 Jun 6 16:25 configure.sh
$ echo '#$Id$' >>configure.sh
$ cvs commit -m test configure.sh
pauls@cvs's password:
Checking in configure.sh;
/develop/cvsroot/shotgun/configure.sh,v <-- configure.sh
new revision: 1.8; previous revision: 1.7
done
$ ls -al configure.sh
-rw-r--r-- 1 pauls pauls 1563 Jul 30 16:51 configure.sh
-----Original Message-----
From: Mark D. Baushke [mailto:mdb@cvshome.org]
Sent: July 30, 2003 3:09 PM
To: Paul Shields
Cc: bug-cvs@gnu.org
Subject: Re: cvs not ignoring permissions
Hi Paul,
Paul Shields <pauls@stabilia.com> writes:
> Some of you may not think this is a bug; but currently this
> mis-feature is interfering with my use of cvs when the working
> directory is shared among several developers.
Sharing a working directory among multiple developers is possible, but
not advisable.
> I am running a cvs 1.11.6 client on a debian linux. The working files
> are checked out from a repository on another host, (using cvs over
> ssh). When you commit a file, it seems that cvs removes the group
> write permission, on the working file.! This seems to happen even if
> my umask is 002. This is an error. I don't care what permission gets
> removed in the repository, I just want to continue sharing the working
> file with the other developers.
I am unable to reproduce your problem on a Redhat 7.3 GNU/Linux system
with a cvs-1.11.6, the remote server is running FreeBSD 4.8-RELEASE in
this particular case.
% ssh server umask
0022
% umask 002
% umask
0002
% export CVSROOT=server:/tmp/testit
% cvs init
% cvs co CVSROOT
U CVSROOT/checkoutlist
U CVSROOT/commitinfo
U CVSROOT/config
U CVSROOT/cvswrappers
U CVSROOT/editinfo
U CVSROOT/loginfo
U CVSROOT/modules
U CVSROOT/notify
U CVSROOT/rcsinfo
U CVSROOT/taginfo
U CVSROOT/verifymsg
% ls -lG CVSROOT
total 48
-rw-rw-r-- 1 mdb 493 Jul 30 11:50 checkoutlist
-rw-rw-r-- 1 mdb 760 Jul 30 11:50 commitinfo
-rw-rw-r-- 1 mdb 987 Jul 30 11:50 config
drwxrwxr-x 2 mdb 4096 Jul 30 11:50 CVS/
-rw-rw-r-- 1 mdb 602 Jul 30 11:50 cvswrappers
-rw-rw-r-- 1 mdb 1025 Jul 30 11:50 editinfo
-rw-rw-r-- 1 mdb 1141 Jul 30 11:50 loginfo
-rw-rw-r-- 1 mdb 1151 Jul 30 11:50 modules
-rw-rw-r-- 1 mdb 564 Jul 30 11:50 notify
-rw-rw-r-- 1 mdb 649 Jul 30 11:50 rcsinfo
-rw-rw-r-- 1 mdb 879 Jul 30 11:50 taginfo
-rw-rw-r-- 1 mdb 1026 Jul 30 11:50 verifymsg
% cd CVSROOT
% echo '#' >> rcsinfo
% cvs ci -m test rcsinfo
Checking in rcsinfo;
/tmp/testit/CVSROOT/rcsinfo,v <-- rcsinfo
new revision: 1.2; previous revision: 1.1
done
cvs server: Rebuilding administrative file database
% ls -lG rcsinfo
-rw-rw-r-- 1 mdb 651 Jul 30 12:06 rcsinfo
% cvs version
Client: Concurrent Versions System (CVS) 1.11.6 (client/server)
Server: Concurrent Versions System (CVS) 1.11.6 (client/server)
% printenv CVS_RSH
ssh
%
If this the problem you are reporting, then show us the commands
that you use to reproduce the problem.
> Please fix the cvs command so that a commit will actually ignore the
> group permission.
What cvs does with the ,v file permissions is not relevant to what is
used on checkout.
> I know about PreservePermissions, but it's not what I want. I
> understand from the manual, as follows:
> http://www.cvshome.org/docs/manual/cvs-1.11.6/cvs_15.html#SEC112
> In normal circumstances, CVS works only with regular files.
Yes.
> Every file in a project is assumed to be persistent; it must be
> possible to open, read and close them; and so on. CVS also ignores
> file permissions and ownerships, leaving such issues to be resolved by
> the developer at installation time. In other words, it is not possible
> to "check in" a device into a repository; if the device file cannot be
> opened, CVS will refuse to handle it. Files also lose their ownerships
> and permissions during repository transactions.
I do not see how this is relevant to your bug report.
-- Mark