Re: Repo packing with subversion 1.6 results

Thanks for the info guys.
Just for completeness: the OS I used for testing was ubuntu 8.10.

Just as a side note: I found 1.6 a pain to build from source due to reliance
on newer versions of some components. I had to hack configure to avoid some
configuration errors as I was not interested in building all the access
modules. Perhaps configure can be improved going forward to make it a bit
more user friendly.
 
Cheers
Jarek

Hyrum K. Wright-3 wrote:
>
> On Mar 27, 2009, at 12:54 AM, B Smith-Mannschott wrote:
>
>> On Fri, Mar 27, 2009 at 02:45, svnuser <jzaniewski_at_gmail.com> wrote:
>>> I have sharded repo using 1.5.6 with 22K revisions, size 2.9G
>>> I loaded its dumps into a new repo using 1.5.1 (I meant to use
>>> 1.5.6 but
>>> this should do)
>>> My new repo has the same size as my original (expected).
>>> I run upgrade/packing on it with 1.6 and all I save is 100M.
>>>
>>> I load the dumps again but this time I use 1.6 and my repo is now
>>> 2G. I do
>>> the packing and my repo shrinks by 100M.
>>>
>>> Are these expected results?
>>
>> Yes
>
> Depending on the size of the revisions (the amount of "stuff" in them)
> and the underlying OS filesystem, packing will have varying amounts of
> benefit. Generally, the space savings will be proportional to the
> number of versions in the repository.
>
>>> Why such diff in size loading with 1.6?
>>> btw my repo is mostly source code but I do have some binaries.
>>
>> <http://subversion.tigris.org/svn_1.6_releasenotes.html#filesystem-improvements
>> >
>>
>> # 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://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1440247
>
> The major decreases you are seeing are from rep-sharing, as noted
> above. For rep-sharing to work, the rep-cache has to be populated,
> which happens when you load the dumpfile on the 1.6 repository. Doing
> an 'svnadmin upgrade' to 1.6-format will enable rep-sharing going
> forward, but it does not populate the cache with existing revisions,
> nor rewrite old history to use rep-sharing.
>
> -Hyrum
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1443571
>
> To unsubscribe from this discussion, e-mail:
> [users-unsubscribe_at_subversion.tigris.org].
>
>

-- 
View this message in context: http://www.nabble.com/Repo-packing-with-subversion-1.6-results-tp22734691p22752408.html
Sent from the Subversion Users mailing list archive at Nabble.com.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1450375
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].