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

[PATCH] Few more observations to bdb/notes/structure

From: Kamesh Jayachandran <kameshj_at_fastmail.fm>
Date: 2006-03-07 08:51:02 CET

Hi All,
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.

With regards
Kamesh Jayachandran

[[
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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 8 15:51:13 2006

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.