From owner-ctm-users@FreeBSD.ORG Wed Aug 10 23:21:35 2011 Return-Path: Delivered-To: ctm-users@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE98F106566B; Wed, 10 Aug 2011 23:21:35 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from wilberforce.math.missouri.edu (wilberforce.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 6F3BA8FC14; Wed, 10 Aug 2011 23:21:35 +0000 (UTC) Received: from [127.0.0.1] (wilberforce.math.missouri.edu [128.206.184.213]) by wilberforce.math.missouri.edu (8.14.4/8.14.4) with ESMTP id p7ANLRdU037763; Wed, 10 Aug 2011 18:21:27 -0500 (CDT) (envelope-from stephen@missouri.edu) Message-ID: <4E431277.6070400@missouri.edu> Date: Wed, 10 Aug 2011 18:21:27 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Julian H. Stacey" References: <201108102304.p7AN4Avk086473@fire.js.berklix.net> In-Reply-To: <201108102304.p7AN4Avk086473@fire.js.berklix.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ctm-users@freebsd.org" Subject: Re: rep-cache.db: was SVN repo X-BeenThere: ctm-users@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CTM User discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 23:21:35 -0000 On 08/10/2011 06:04 PM, Julian H. Stacey wrote: > Hi Stephen& all > >> I created a .0001 delta for svn. It is about 5G. When compressed with >> gzip, it goes down to 1.8G. When compressed with bzip2, it goes down to >> 1.4G. When compressed with xz, it goes down to 1G. These are some huge >> differences in my opinion. > > Yup ! Too big to ignore. Just in case, > did you possibly overlook ensuring comparing like with like ? eg: > > man gzip > -9, --best These options change the compression level used, with > the -1 option being the fastest, with less compression, > and the -9 option being the slowest, with optimal com- > pression. The default compression level is 6. > BTW I have : printenv | grep -i gzip # GZIP=--best > > man bzip2: > And --best merely selects the default behaviour. > > man xz > -0 ... -9 > Select a compression preset level. The default is -6. > ...... > The CTM's are created with "gzip -9." For bzip2 and xz I simply checked default behavior. But bzip2 is already best by default. Tests I have done in the past suggest that the difference created by adjusting these numbers is not very great. I think what happens is that the compression program splits the file into parts, and then compresses each part. The -n options simply say how big those parts can be. As you can imagine, making these parts super big will bring diminishing returns. > >> If FreeBSD were to switch to svn, and stop supporting cvs, how many >> people would be negatively impacted by not having svn on CTM? > > I'd miss it. I could live without, > I could doubtless switch to running csup of ctm then svn, > (but dont much want to punch another hole in firewall, I get the impression that svn is via ssh. Do you have ssh blocked in your firewall? > figure packet proxying (cos gate disk too small), > &/or fix my ftp proxy (only my http proxy works) > I could fix or reconfig all, but I'd miss it :-), > ctm via email, fed to local cvs tree has always been just so > nice& efficient, allowing lots of offline for max security&/or > better response for other interactive stuff,& quick load to laptop > for travel, whatever. > > >> I tried deleting base/db/repo-cache.db. > > I have the book Version Control with Subversion 2nd Ed. but never read it, I found an online book on svn. I think it was this book. I searched this book for rep-cache.db, but it came up blank. > Maybe you might find an SVN expert to discuss with on one of the SVN lists at > http://lists.freebsd.org/mailman/listinfo > maybe > http://lists.freebsd.org/mailman/listinfo/svn-src-svnadmin I might do that, but probably not in the near future. > > Thanks for all the CTM work you do for us ! > > Cheers, > Julian