Ashod Nakashian wrote on Wed, Apr 04, 2012 at 10:18:47 -0700: > >________________________________ > > From: Daniel Shahaf <danie...@elego.de> > >To: Ashod Nakashian <ashodnakash...@yahoo.com> > >Cc: Markus Schaber <m.scha...@3s-software.com>; "julianf...@btopenworld.com" > ><julianf...@btopenworld.com>; "mtheri...@gmail.com" <mtheri...@gmail.com>; > >Subversion Development <dev@subversion.apache.org> > >Sent: Wednesday, April 4, 2012 9:46 AM > >Subject: Re: Compressed Pristines (Summary) > > > >> >1. Filesystem compression. > >> > > >> >Would you like to assess the feasibility of compressing the pristine > >> >store by re-mounting the "pristines" subdirectory as a compressed > >> >subtree in the operating system's file system? > >> > >> No :-) > >> > >> There are two ways to answer this interesting proposition of > >> compressed file-systems. The obvious one is that it isn't something > >> SVN can or should control. The file-system and certainly system > >> drivers are up to the user and any requirement or suggestion of > >> tempering with them is decidedly unwarranted and unexpected from > >> a VCS. > > > >The suggestion wasn't that you teach svn how to change the OS's fs > >settinsg, it was that you investigate how solutions at the OS level > >compare to the other approaches already suggested (custom format -based > >and sqlite-based pristine store). > > That's an easy question. The answer is that at *best* they'll do as > good as in-place compression. However, in practice they'll do much > worse. The reason is that the OS level compression works on not only
Is it _necessarily_ that way? What does Subversion about the pristine store's contents know that the filesystem doesn't? > the single file level, but actually at the block level. This is to > make modifications reasonably fast (read compressed data, uncompress, > modify, write recompressed data). If the complete file is compressed > then even changing a single byte (neglecting that no storage works on > the byte-level anyway) will yield performance that will at least > linearly degrade by the filesize. > > > > > >In short: if 'mount -o compress=yes' provides 90% space savings then we > >would have little reason to implement space-saving solutions in svn itself. > >But it's the user's, not svn's, responsibility to run that. > > > I should kindly disagree here. The user can do that any time, anyway. > SVN is trying to improve its pristine store design, No we don't. We're trying to provide users with a low-footprint pristine store. If we can achieve that by tuning OS settings we might not need to write code. > not advise users > on how best to organize their storage (in general or when using SVN). > In addition, I find discriminating against users who don't have that > luxury or knowledge to be a bit unfair. At least if are claiming to > support the wide range of systems that we do. > Yes, I edited that out of my previous email: we should ensure that "low-footprint pristine store" is achievable on most/all platforms we support. Also, agreed that we should consider the case of users don't have permissions to tune their OS settings but have working copies. > -Ash > > > >
