From: Ann Barcomb Date: 11:45 on 31 Aug 2004 Subject: CVS hatred There are so many things to hate about CVS. I listed many of them in a previous complaint roughly a year ago. I'm still hating it. When I commit a file, permissions are changed in accordance with my default umask. Why? It isn't as if the file even needs to be modified locally. Even if it was, it would make more sense to retain the permissions I have set. I could understand an update modifying permissions, perhaps. But a commit? That means "I'm happy with this exactly the way it is, and I want to save it." While it is true that I generally want my default umask or it wouldn't be my default, I often modify this, for example by giving access to lib files to other. It is not infrequent that a program doesn't work, and when I backtrack to figure out why it turns out that the library permissions are incorrect. Isn't version control supposed to make my life easier?
From: peter (Peter da Silva) Date: 11:59 on 31 Aug 2004 Subject: Re: CVS hatred > When I commit a file, permissions are changed in accordance with my default > umask. Why? It isn't as if the file even needs to be modified locally. Not even to update the version number in the CVS comment?
From: Ann Barcomb Date: 12:54 on 31 Aug 2004 Subject: Re: CVS hatred Peter wrote: > > When I commit a file, permissions are changed in accordance with my default > > umask. Why? It isn't as if the file even needs to be modified locally. > > Not even to update the version number in the CVS comment? I'm not using any CVS variables in the file, so as far as I know it should only need to write to CVS/Entries.
From: Peter Pentchev Date: 09:19 on 03 Sep 2004 Subject: Re: CVS hatred --VkVuOCYP9O7H3CXI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 31, 2004 at 04:54:42AM -0700, Ann Barcomb wrote: > Peter wrote: >=20 > > > When I commit a file, permissions are changed in accordance with my d= efault > > > umask. Why? It isn't as if the file even needs to be modified local= ly. > > > > Not even to update the version number in the CVS comment? >=20 > I'm not using any CVS variables in the file, so as far as I know it should > only need to write to CVS/Entries. Well, if you are not using any CVS keywords, then why don't you just say so? CVS has keyword expansion flags for that, especially -ko, although -kb might also be desirable in some cases. Of course, this will not help when you check out or update your work on the production servers, but at least on your development machines ko-marked scripts will not be touched. Script started on Fri Sep 3 11:13:05 2004 [roam@straylight ~/lang/sh]> setenv LANG C [roam@straylight ~/lang/sh]> mkdir permtest [roam@straylight ~/lang/sh]> cd permtest [roam@straylight ~/lang/sh/permtest]> cat > normal.sh #!/bin/sh echo '$Ringlet$' [roam@straylight ~/lang/sh/permtest]> cp normal.sh ko.sh [roam@straylight ~/lang/sh/permtest]> cp normal.sh kb.sh [roam@straylight ~/lang/sh/permtest]> chmod 777 *.sh [roam@straylight ~/lang/sh/permtest]> ls -l total 6 -rwxrwxrwx 1 roam 1001 27 Sep 3 11:13 kb.sh -rwxrwxrwx 1 roam 1001 27 Sep 3 11:13 ko.sh -rwxrwxrwx 1 roam 1001 27 Sep 3 11:13 normal.sh So, now we have three files with silly modes. [roam@straylight ~/lang/sh/permtest]> cd .. [roam@straylight ~/lang/sh]> cvs add permtest Directory /home/cvs/ringlet/sh/permtest added to the repository [roam@straylight ~/lang/sh]> cd permtest [roam@straylight ~/lang/sh/permtest]> cvs add normal.sh cvs add: scheduling file `normal.sh' for addition cvs add: use 'cvs commit' to add this file permanently [roam@straylight ~/lang/sh/permtest]> cvs add -ko ko.sh cvs add: scheduling file `ko.sh' for addition cvs add: use 'cvs commit' to add this file permanently [roam@straylight ~/lang/sh/permtest]> cvs add -kb kb.sh cvs add: scheduling file `kb.sh' for addition cvs add: use 'cvs commit' to add this file permanently [roam@straylight ~/lang/sh/permtest]> date Fri Sep 3 11:14:03 EEST 2004 [roam@straylight ~/lang/sh/permtest]> cvs ci -m 'Permissions test' *.sh RCS file: /home/cvs/ringlet/sh/permtest/kb.sh,v done Checking in kb.sh; /home/cvs/ringlet/sh/permtest/kb.sh,v <-- kb.sh initial revision: 1.1 done RCS file: /home/cvs/ringlet/sh/permtest/ko.sh,v done Checking in ko.sh; /home/cvs/ringlet/sh/permtest/ko.sh,v <-- ko.sh initial revision: 1.1 done RCS file: /home/cvs/ringlet/sh/permtest/normal.sh,v done Checking in normal.sh; /home/cvs/ringlet/sh/permtest/normal.sh,v <-- normal.sh initial revision: 1.1 done [roam@straylight ~/lang/sh/permtest]> ls -l total 8 drwxr-xr-x 2 roam 1001 512 Sep 3 11:14 CVS -rwxrwxrwx 1 roam 1001 27 Sep 3 11:13 kb.sh -rwxrwxrwx 1 roam 1001 27 Sep 3 11:13 ko.sh -rwxr-xr-x 1 roam 1001 86 Sep 3 11:14 normal.sh Yep, according to the modification times, normal.sh was overwritten, but ko.sh and kb.sh were not touched at all - so CVS seems to DTRT indeed for -ko and -kb expansion modes. [roam@straylight ~/lang/sh/permtest]> ./normal.sh=20 $Ringlet: sh/permtest/normal.sh,v 1.1 2004/09/03 08:14:10 roam Exp $ [roam@straylight ~/lang/sh/permtest]> ./ko.sh=20 $Ringlet$ [roam@straylight ~/lang/sh/permtest]> ./kb.sh=20 $Ringlet$ [roam@straylight ~/lang/sh/permtest]> exit exit Script done on Fri Sep 3 11:14:23 2004 One could certainly argue that CVS should do the same for the normal keyword expansion mode (-kkv), if there really are no keywords to be expanded in the file, and IMHO one would be right to say so :) Still, it seems that -ko does provide some consolation. G'luck, Peter --=20 Peter Pentchev roam@xxxxxxx.xxx roam@xxxxx.xx roam@xxxxxxx.xxx PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am jealous of the first word in this sentence. --VkVuOCYP9O7H3CXI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBOCku7Ri2jRYZRVMRArSpAJ9Mtp9aL98ar2vflCv9UVfGeeQxcwCfdQ2C 9i5A0EZa1VlLyrX4Gqb57rk= =YTLA -----END PGP SIGNATURE----- --VkVuOCYP9O7H3CXI--
From: Ann Barcomb Date: 10:05 on 03 Sep 2004 Subject: Re: CVS hatred On Fri, 3 Sep 2004, Peter Pentchev wrote: > Well, if you are not using any CVS keywords, then why don't you just > say so? CVS has keyword expansion flags for that, especially -ko, > although -kb might also be desirable in some cases. Of course, this > will not help when you check out or update your work on the production > servers, but at least on your development machines ko-marked scripts > will not be touched. Hmm, probably because I didn't know of that flag. I have used -kb on occassion, but not in order to prevent permission changes. However, I think it is probably not worth setting these flags because I still won't have the changes on other checkouts. It would be better to write a script which sets permissions correctly and is run at regular intervals. All in all, a tarball is sounding like a better way of updating a live server. It also seems to me that it should be possible to determine whether keywords are actually used or not and respond accordingly, if the file is in a setting which allows keywords. But the real point, as I see it, is that it is not logical that checking in a file which may contain a CVS keyword changes the permissions on the file. I can understand how it happens (probably because of an rm and a new file instead of a modification of the old file), but if I wasn't able to imagine an implementation which could cause that side effect, how would I ever be able to guess that the way to avoid it would be to eliminate the opportunity for CVS to use keywords? You will note that I didn't guess it, even with the implementation possibility in my mind. There is simply no logical relationship between the task of saving a file and automatically changing the permissions of the file. A search for 'permission' in the man page doesn't mention the solution of -ko to avoid changes in file permissions--and why should it? That's not what the flag is really for. I pity someone who wants to use keywords and doesn't have the -ko solution available. And I still pity myself, because I want to preserve file permissions across checkouts, and it looks like I'll have to write a script and keep it up to date in parallel with CVS. - Ann
From: Peter Pentchev Date: 10:16 on 03 Sep 2004 Subject: Re: CVS hatred --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 03, 2004 at 02:05:18AM -0700, Ann Barcomb wrote: > On Fri, 3 Sep 2004, Peter Pentchev wrote: >=20 > > Well, if you are not using any CVS keywords, then why don't you just > > say so? CVS has keyword expansion flags for that, especially -ko, > > although -kb might also be desirable in some cases. Of course, this > > will not help when you check out or update your work on the production > > servers, but at least on your development machines ko-marked scripts > > will not be touched. >=20 > Hmm, probably because I didn't know of that flag. I have used -kb on > occassion, but not in order to prevent permission changes. >=20 > However, I think it is probably not worth setting these flags because > I still won't have the changes on other checkouts. It would be better > to write a script which sets permissions correctly and is run at > regular intervals. >=20 > All in all, a tarball is sounding like a better way of updating a live > server. IMHO, the best way would be to write a couple of Makefile's, checkout in a separate location, and then 'make install DESTDIR=3D/whatever' (or DESTDIR could even be defined with a '?=3D' in the Makefile itself). Then the Makefile's would use install(1) with appropriate -o, -g and -m flags, and everything will be just fine. =09 > But the real point, as I see it, is that it is not logical that > checking in a file which may contain a CVS keyword changes the > permissions on the file. I can understand how it happens (probably > because of an rm and a new file instead of a modification of the old > file), but if I wasn't able to imagine an implementation which could > cause that side effect, how would I ever be able to guess that the > way to avoid it would be to eliminate the opportunity for CVS to > use keywords? You will note that I didn't guess it, even with > the implementation possibility in my mind. >=20 > There is simply no logical relationship between the task of saving > a file and automatically changing the permissions of the file. True. I wonder if it would be hard to add a stat()/chmod() to CVS; I'll look into that sometime soon (been looking through the CVS sources recently for unrelated reasons). G'luck, Peter --=20 Peter Pentchev roam@xxxxxxx.xxx roam@xxxxx.xx roam@xxxxxxx.xxx PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am not the subject of this sentence. --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBODZ97Ri2jRYZRVMRAvC5AJ0botwdfHAVKvd2SKWEj2IoQZaG9wCgtKBv YQRFkVrorxKQU8wMvb8gz0w= =xycc -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk--
From: Ann Barcomb Date: 10:26 on 03 Sep 2004 Subject: Re: CVS hatred On Fri, 3 Sep 2004, Peter Pentchev wrote: > IMHO, the best way would be to write a couple of Makefile's, checkout in > a separate location, and then 'make install DESTDIR=/whatever' (or > DESTDIR could even be defined with a '?=' in the Makefile itself). Then > the Makefile's would use install(1) with appropriate -o, -g and -m > flags, and everything will be just fine. The way I see it, I need to: * maintain permissions after checkins on the development server * set permissions correctly when doing a new checkout/installation * maintain permissions when doing an update on development + live A make file is only going to handle the second one, so I'd rather come up with one solution that addresses all needs and doesn't require me to look in the cvs source. But that's just me. > > There is simply no logical relationship between the task of saving > > a file and automatically changing the permissions of the file. > True. I wonder if it would be hard to add a stat()/chmod() to CVS; I'll > look into that sometime soon (been looking through the CVS sources > recently for unrelated reasons). This would be a nice way to improve cvs. I suspect it needs a chown for the right group ownership as well.
From: Daniel Pittman
Date: 11:01 on 03 Sep 2004
Subject: Re: CVS hatred
On 3 Sep 2004, Ann Barcomb wrote:
> On Fri, 3 Sep 2004, Peter Pentchev wrote:
>
>> IMHO, the best way would be to write a couple of Makefile's, checkout in
>> a separate location, and then 'make install DESTDIR=/whatever' (or
>> DESTDIR could even be defined with a '?=' in the Makefile itself). Then
>> the Makefile's would use install(1) with appropriate -o, -g and -m
>> flags, and everything will be just fine.
>
> The way I see it, I need to:
> * maintain permissions after checkins on the development server
> * set permissions correctly when doing a new checkout/installation
> * maintain permissions when doing an update on development + live
>
> A make file is only going to handle the second one, so I'd rather
> come up with one solution that addresses all needs and doesn't require
> me to look in the cvs source. But that's just me.
For what it is worth, this is one of the issues the Subversion project
set out to address.
Now, subversion itself is something well worthy of hate, but it does
seem to get the metadata issues right.
Daniel
From: Darrell Fuhriman Date: 16:24 on 03 Sep 2004 Subject: Re: CVS hatred > Now, subversion itself is something well worthy of hate, but it does > seem to get the metadata issues right. Merging branches in subversion seems to sometimes border on magic. That being said, it does suck marginally less than CVS, but in entirely different ways. But for my money, 'svn move' makes it well worth it over CVS. Darrell
From: Peter Pentchev Date: 11:08 on 03 Sep 2004 Subject: Re: CVS hatred --3Gf/FFewwPeBMqCJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 03, 2004 at 02:26:53AM -0700, Ann Barcomb wrote: > On Fri, 3 Sep 2004, Peter Pentchev wrote: [snip] > > True. I wonder if it would be hard to add a stat()/chmod() to CVS; I'll > > look into that sometime soon (been looking through the CVS sources > > recently for unrelated reasons). >=20 > This would be a nice way to improve cvs. I suspect it needs a chown > for the right group ownership as well. That's funny. I just found the underdocumented 'PreservePermissions' option. If you are running a CVS client and server more recent than 1.9.26 (and you should! ;), try editing the repository's CVSROOT/config file and adding or setting 'PreservePermissions=3Dtrue'. This just might help :) I'm not sure if it would at all work with a remote repository, though - never tested it. G'luck, Peter --=20 Peter Pentchev roam@xxxxxxx.xxx roam@xxxxx.xx roam@xxxxxxx.xxx PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence contradicts itself - or rather - well, no, actually it doesn'= t! --3Gf/FFewwPeBMqCJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBOEKs7Ri2jRYZRVMRAtRTAKDD0Ny9xdk2GRW8cv3wWT+NXJtbAQCcD2e3 ALWk5Gu3cweHAn55lW7LNQ0= =Y90u -----END PGP SIGNATURE----- --3Gf/FFewwPeBMqCJ--
Generated at 17:46 on 21 Sep 2006 by mariachi