On Wed, Jan 15, 2014 at 02:49:37PM +0100, Olivier Berger wrote: > > Hi. > > At repository creation, the db/rep-cache.db isn't created respecting the > current umask. > > This leads to producing warnings at commit time. > > See http://subversion.tigris.org/issues/show_bug.cgi?id=3437 for details. > > This seems to be fixed post 1.8.5. >
AFAIU, the file may be touched before the first commit is made, so that sqlite will not try to create it with wrong mask, and we are safe. This is the workaround I'll suggest for fusionforge (see #735440). However, if repositories have received commits whereas the bug was already present, then I fear some inconsistency if the perms are restored as writable for committers, and some later commits are the only ones in the cache. I haven't found a mention of a tool that'd rebuild the cache, and the removing the file just postpones the problem (it will be recreated, with wrong mask, and will only contain the later commits). Note that the upstream docs seem to be wrong in this respect (http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure) mentioning that "This file is only consulted during writes and never during reads. Consequently, it is not required, and may be removed at an abritrary time, with the subsequent loss of rep-sharing capabilities for revisions written thereafter." Or maybe if the rep-cache.db isn't complete doesn't do harm ? I'll try and ask upstream for what to do for existing repositories that exhibited the problem. Hope this helps. Best regards, -- Olivier BERGER http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
