Return-Path: X-Original-To: apmail-subversion-users-archive@minotaur.apache.org Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 2875EC2C1 for ; Tue, 11 Jun 2013 12:53:31 +0000 (UTC) Received: (qmail 69593 invoked by uid 500); 11 Jun 2013 12:53:30 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 69248 invoked by uid 500); 11 Jun 2013 12:53:26 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 69241 invoked by uid 99); 11 Jun 2013 12:53:25 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Jun 2013 12:53:25 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of cmpilato@collab.net designates 204.16.106.213 as permitted sender) Received: from [204.16.106.213] (HELO exch-smtp.collab.net) (204.16.106.213) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Jun 2013 12:53:18 +0000 Received: from [10.10.10.245] (204.16.106.217) by EXCH01.sp.corp.collab.net (204.16.106.213) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 11 Jun 2013 05:52:56 -0700 Message-ID: <51B71DA0.3030507@collab.net> Date: Tue, 11 Jun 2013 14:52:48 +0200 From: "C. Michael Pilato" Organization: CollabNet, Inc. User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Thomas Harold CC: Subject: Re: svn 1.8 migration - directory deltification and revprop packing References: <51B5CF22.6080501@nybeta.com> In-Reply-To: <51B5CF22.6080501@nybeta.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2NHEJDKKBONTMDQPKNFOL" X-Virus-Checked: Checked by ClamAV on apache.org ------enig2NHEJDKKBONTMDQPKNFOL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable One advantage of being in a room full of Subversion developers, specifica= lly the guy that implemented all this stuff, is that I can ask him directly about how to respond to this mail. :-) Hopefully I will accurately represent the answers Stefan Fuhrmann just gave me to your questions. On 06/10/2013 03:05 PM, Thomas Harold wrote: > a) Why are directory/property deltifications turned off by default? Stefan's jovial first answer was, "Because I'm a chicken." :-) Fortunately, he didn't stop there. He explained that there is no known correctness risk -- you're not going to damage your repositories by enabl= ing the feature. But he wanted to phase in the feature to allow time to coll= ect real-world data about the amount of space savings folks are actually observing in their repositories. The feature is on by default in his proposed next version of the FSFS format. > b) Is there a global setting file that can be used to enable > directory/property deltifications? Or will we have to update the fsfs.c= onf > file for each newly created repository in order to get this feature? In 1.8, you'll need to toggle this for each new repository manually. > c) Is it a safe assumption that in order to apply this change to an old= er > repository that we will need a dump/load cycle? Will we need a full du= mp or > will an delta style dump suffice (--deltas option of svnadmin dump comm= and)? Not exactly. You can apply the change to an older repository sitting beh= ind a server still running 1.8, and any new directory/property lists will be stored in a deltified fashion. If you want retroactive deltification of existing data, then yes, you'll need to dump and load your repositories. But as explained in the release notes, you can dump and re-load right bac= k into a previous version of the repository format if you'd prefer to maint= ain compatibility with older server versions. As for the --deltas option, that has nothing in the world to do with the types of deltas we're discussing here. (As an aside, I would highly recommend that, unless you need your dumpfiles to be smaller, avoid the --deltas option. The performance penalty of using it isn't worth it.) > #2 - revision property (revprops) files packing >=20 > a) Will there be a "svnadmin pack" command like there was for SVN 1.6? = Or > will we need to do a full dump/load of the repository to pack the revpr= ops? The existing 'svnadmin pack' command will govern both revision and revpro= p packing, and will keep the two in sync with each other. 'svnadmin upgrad= e' will also take the opportunity to synchronize the packing status of the revision properties with that of the revision backing files. > b) Does revprop caching only need to be enabled for http/https access a= nd > does it have any effect on svn+ssh access? (All of our users currently= use > svn+ssh access, but we are considering moving to http/https.) Each server has its own cache enable/disable configuration mechanisms, an= d both benefit from the revprop caching being enabled. --=20 C. Michael Pilato CollabNet <> www.collab.net <> Enterprise Cloud Development ------enig2NHEJDKKBONTMDQPKNFOL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJRtx2gAAoJEPXg8AH+aBMzoiYP/0aGa3vgfdUeYrse5cXfI2Ri oya0lP+ZfibcInUGMVPbZH4Km+skcOveD32xFp5B2lrrnCBgCZZownblMEwq638x rbOjuH897oVi06IoAAE95qjZYsRYeAFW586+RY427ClJqguGoaKzkUXYlngZbwIA CCxqvAAA9UUS5x7uvUYeEWqdqCzc2XoEcZ9WG6xf0e5MkRc5iZEOqXZuugoJzKHA iS6hBvnABSkzdQqkjaywrjybjODoSMJAEzinBvFLHbPESpyb4Sn5Vg3B12TNge6K Qmof+LwXyPOZLwuDlKm0qPnI9Z4xGiVqyQX8d+Zt/MbLezRuEQ+Ite2CBpREnGyh 09YbcIWAqjY6gBKGdtHGSsq7QY1NHHUdAgqZzKcuuVrrfAtfleqcF8BzoAqDCXEX YOpDhEkvFX5ag2yMCyRz6fLeTe3N1JPzVZpVgKm0fq51/jK9WVs7f6lIuEv3MSI/ lqtpmDLyUgOzTEuoo5/Ndohlb3frgASJPp3cRcJiqFTUMmkozhIQHJFcs27IZ9CO Obqa1jS8fmxpQHH8ECWGX4Kpm+igQ/n2KklxBdFdQ6sIFMeiajbNdqo8ivr1/XPA 2tJ9EaIUPSoB18BL6PK1A51xY4C9SWrLEOm8TFoiOJFMiHKodJRr7IVEmkk+lAy0 HLXiXvM5EVJu+7/Jjlpn =vIZc -----END PGP SIGNATURE----- ------enig2NHEJDKKBONTMDQPKNFOL--