Re: [Savannah-hackers-public] Read-only files in www's CVS repository

[Yavor Doganov]

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.