[Top][All Lists]

[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 
$ 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
$ 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
  % umask 002
  % umask
  % 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
  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

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.


> 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

reply via email to

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