Re: [PATCH]Want to incorporate few of the learning I had in subversion/libsvn_fs_base/notes/structure doc.

Kamesh Jayachandran <kamesh@collab.net> writes:
> While trying to understand the
> subversion/libsvn_fs_base/notes/structure doc side by side with
> 'db_dump -p /path/to/repos/db/representations', got baffled by seeing
> subversion storing first 10 revisions of my simple text file commits
> as 'fulltext'.
> When delved for the cause, found that before deltifying the
> 'youngest-1' storage gain is evaluated if there is a gain in 'delta'
> representation 'youngest-1' is deltified against 'youngest' or else
> 'youngest-1' as 'fulltext'. Just wanted to mention the same in the
> structure document.
>
> Find the attached patch.
>
> [[
> Mention of storage gain evaluation while deciding 'fulltext'/'delta'
> representation of youngest-1.
>
> Patch by: Kamesh Jayachandran <kamesh@collab.net>
>
> * subversion/libsvn_fs_base/notes/structure
> Mention of storage gain evaluation while deciding 'fulltext'/'delta'
> representation of youngest-1.
> ]]]
> Index: subversion/libsvn_fs_base/notes/structure
> ===================================================================
> --- subversion/libsvn_fs_base/notes/structure (revision 18733)
> +++ subversion/libsvn_fs_base/notes/structure (working copy)
> @@ -355,8 +355,13 @@
> tables together handle deltification and undeltification
> *independently* of ancestry. At present, Subversion generally stores
> the youngest strings in "fulltext" form, and older strings as "delta"s
> -against them. However, there's nothing magic about that particular
> -arrangement. Other interesting alternatives:
> +against them. Subversion does a storage gain evaluation before
> +adopting the 'youngest in "fulltext"' and 'youngest-1 in "delta" strategy'.
> +If "delta" representation of 'youngest-1' is of size more than "fulltext"
> +representation of 'youngest-1' it leaves the 'youngest-1' as "fulltext".
> +So it is not strange to see many "fulltext" representations of node revisions.
> +However, there's nothing magic about that particular arrangement.
> +Other interesting alternatives:
>
> * We could store the N most recently accessed strings as fulltexts,
> letting access patterns determine the most appropriate

I committed r18761 based on your suggestion. However, I compressed it
into a small parenthetical aside, to avoid distracting from the main
point of that passage.

Thanks,
-Karl

-- 
www.collab.net  <>  CollabNet  |  Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org