Hi. Olivier Berger <[email protected]> writes:
> Thorsten Glaser <[email protected]> writes: > >> On Thu, 16 Jan 2014, Olivier Berger wrote: >> >>> Are you suggesting that this wouldn't happen if we configured the SVN >>> repos differently, i.e. is only a side effect ? >>> >>> Can you elaborate on the enable-rep-sharing = false ? >> >> Basically, setting “enable-rep-sharing = false” disables >> that SQLite crap, AFAICT from my duckduckgoïng around. > > OK, but it is unclear to me what exactly enable-rep-sharing is > controlling... I haven't yet found a piece of docs explaining that :-/ > Still searching... > Responding to myself as I have finally found relevant information, I think : - http://subversion.apache.org/docs/release-notes/1.6.html#rep-sharing "Sharing multiple common representations (issue 2286, server) When using many branches and merging between them often, it is common to have files with similar lines of history which contain the exact same content. In the past, Subversion has stored these files as deltas against previous versions of the file. Subversion 1.6 will now use existing representations in the filesystem for duplicate storage. Depending on the size of the repository, and the degree of branching and merging, this can cause an up to 20% space reduction for Berkeley DB repositories and a 15% reduction for FSFS repositories. - http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure "When representation sharing is enabled, the filesystem tracks representation checksum and location mappings using a SQLite database in "rep-cache.db". The database has a single table, which stores the sha1 hash text as the primary key, mapped to the representation revision, offset, size and expanded size. 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. You just had to figure out that "rep-sharing" stands for "representation sharing" and not "repo sharing" ;-) So what I understand is that the default is representation sharing is activated (even if the fsfs.conf isn't clear about the default value, but there are bug reports upstream on that particular issue, I think), which is supposed to be a good thing disk-space wise, in which case, the DB file ought to be used for performance reason, unless it becomes too big and creates other issues otherwise... So... I'm not sure the right fix is to set enable-rep-sharing to false, but I'd probably prefer to touch an empty file with proper rights before creating the repo, until svn fixes the issue with its sqlite sub-component. Hope this makes sense. 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 [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
