Hi, It turns out that somebody activated 'cvs watch on' at a point. This on a CVS feature where you need to 'cvs edit' before modifying a file, which triggers the 'notify' hook. http://www.network-theory.co.uk/docs/cvsmanual/Settingawatch.html
This creates CVS/fileattr files on the server, which is how I spotted the issue. You can issue a 'cvs watch off' at the root of the working copy (which I just did) to recursively cancel this. I also removed 2 remaining 'CVS/fileattr' files (which referenced removed files in Attic/ and were not removed; they were harmless, but it's cleaner this way). Btw, > I only reported it here after performing the things in this bullet > list; I know you're busy and I still feel guilty about that nefarious > translations project renaming. There's nothing to be guilty about :) However, was there progress with renaming the translation project webpages? I think the renaming stalled there. -- Sylvain On Sat, Jun 14, 2008 at 03:49:46AM +0300, Yavor Doganov wrote: > Sylvain Beucler wrote: > > > > I had a look at po/ and it doesn't look different than the rest of > > the CVS files at Savannah :/ > > Too bad, it basically rules out my theory. > > > Files are created 444 _on the server_ but that's the way CVS set > > permissions for all repositories. > > This is where the oddity comes from. > > * I examined CVSROOT and compared it with other repositories (both Web > and Sources) and I ensured that there are no special things for www > (I wanted to report the problem to www maintainers first with the > hope that somebody knows what's going on, but concluded that it's > not a request made explicitly (in the past) by a www maintainer). > > * I tested this with a Web and Sources reposotory of another project > (trans-coord), and I also checked all cvs logs of all the files in > the www repository (of course only in the root directory plus the > subdirectories I know were created after 2005; doing this on every > file is almost equal to a suicide). By doing so, I was able to > determine the fact that permissions for newly added files since that > date (or year, more "precisely") were read-only, and I all newly > added sub-directories were read-only -- naturallly because they > inherit the permissions of the parent directory. > > * I initally thought this was my fault, so I checked all the recent > commits (in the past 3 years, which turned to be a lot) that I was > sure were done by me (only using Debian and gNewSense machines). > > * Once I figured out that even people `cvs add'-ing files from a > Fedora, certainly-non-Debian or Windows (that's a felony in my book, > but nevertheless) distros and only happening after 2005 and only on > www, and only in the root directory + all sub-directories created > after that suspected date, I decided to report it here. > > * I suspected a bug in CVS, and even a bug introduced in > Debian-specific change of the cvs package since sv.gnu.org runs > Debian and my machines run either Debian or gNewSense. So I checked > the Debian changelog and the bugs in Debian; it smells very much > like http://bugs.debian.org/10448 but I know that if such a bug was > present many Savannah users would yell. > > * I checked out the source of the Debian `cvs' package and examined the > patches (there are a lot), in the hope that this is an obvious typo > that is reproduced only in the peculiar Savannah setup for www since > about 2005. No clues, but of course no guarantees either -- I > surely may miss something. > > I only reported it here after performing the things in this bullet > list; I know you're busy and I still feel guilty about that nefarious > translations project renaming. > > > Can you detail where you see them as read-only (client or server?), > > If you do a cvs export or checkout of www, and then `ls -l' in the > root, you will observe that some files are 644, but some are 444. > > Then (assuming you have repository write permissions and naturally a > working copy): > > touch foo > cvs add foo > touch gnu/foo > cvs add gnu/foo > cvs commit ... > > Will result in `foo' being read-only while `gnu/foo' being 644. If > you add `contact/foo', it will be read-only as well, because the > /contact directory was added after 2005. Likewise, adding > `philosophy/foo' will yield read-write permissions, because > /philosophy was created before this bad event in 2005 (according to my > unproven theory). > > > and what major gried this causes with the new translation system? > > The build system modifies files that exist in the working copy (after > `cvs update') so every command that touches such a file fails. I > workaround this with chmod currently, but there seems to be a general > problem. > > FWIW, I noticed about this weirdness in www (and only in www!) many > many months ago, but because of some RCS reflex/habit, I usually do > `C-x v v' in Emacs without much thinking when the buffer is not > writable. So it is kinda embarrassing that I did not anticipate the > build failure in the official `www' repository... > > Anyway, the workaround does the job, so this is not something urgent. > > > Give me steps to reproduce your problem :) > > I believe I gave them, but unfortunately I made tests only on > Debian-based machines (no other system at my disposal). If anything > else is necessary, of course I think I can easily provide it. >
