[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Compressed Pristines (Summary)

From: Bert Huijben <bert_at_qqmail.nl>
Date: Wed, 4 Apr 2012 13:59:33 -0700

> -----Original Message-----
> From: Ashod Nakashian [mailto:ashodnakashian_at_yahoo.com]
> Sent: woensdag 4 april 2012 13:28
> To: Greg Stein
> Cc: dev_at_subversion.apache.org
> Subject: Re: Compressed Pristines (Summary)
>
> >________________________________
> > From: Greg Stein <gstein_at_gmail.com>
> >My vote is compress for files > N bytes (and store on disk), and stick
the
> others into a new pristine.db. Maybe compress before inserting into
Sqlite.
> Not sure. Add a few heuristics for skipping compression on certain files
> types.
> >Shouldn't be too bad to start with that.
> >Cheers,
> >-g
> >
>
> I feel this is indeed what we're closing on, at least for an initial
working demo.
> But I'd like to hear more agreements before committing to this path. I
know
> some did show support for this approach, but it's hard to track them in
the
> noise.
>
> So to make it easier, let's either voice support to this suggestion and
commit
> to an implementation, or voice objection with at least reasons and
possibly
> alternative action. Silence is passive agreement, so the onus on those
> opposing ;-)

+1
The combination of some compression (gzip or plain deflate), maybe some
specific uncompressed files and the small files in SQLite sounds good.

I think the cutoff point for SQLite should be below what we can have in
memory as we can't keep database transactions open to back up streams. 32K
(and a few times higher) should be safe to read in memory at once.

        Bert
Received on 2012-04-04 23:00:12 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.