Old BDB-backed repositories stored the older revision as fulltext and
newer revisions as deltas.
Really? Here is a quotation from SVN 1.4.6 libsvn_fs_base/note/structure:
At present, Subversion generally stores
the youngest strings in fulltext form, and older strings as deltas
against them
Vyacheslav Zholudev wrote on Fri, Nov 25, 2011 at 11:13:00 +0100:
Old BDB-backed repositories stored the older revision as fulltext and
newer revisions as deltas.
Really?
It seems that I should have swapped older and newer in the quoted
sentence. Thanks for catching that.
Here is a
Hi Daniel,
would it be easy to change the code (I want to do it for my experiments) so
that the HEAD (youngest) revisions are stored as fulltexts? Or is it something
that was not foreseen by design to easily switch between approaches of
representing history information?
Thanks,
Vyacheslav
On
Change SVN_FS_BASE__MIN_FORWARD_DELTAS_FORMAT to be larger than
SVN_FS_BASE__FORMAT_NUMBER.
Whether repositories created by an svn patched in this way will be
interoperable with repositories created by an unpatched svn is
LAAEFTR'd. I'd be cautious and change db/fs-type or db/format.
Vyacheslav
Thanks, Daniel. That's the pointer I needed.
However, I didn't understand what LAAEFTR means.
Vyacheslav
On Nov 25, 2011, at 12:17 PM, Daniel Shahaf wrote:
Change SVN_FS_BASE__MIN_FORWARD_DELTAS_FORMAT to be larger than
SVN_FS_BASE__FORMAT_NUMBER.
Whether repositories created by an svn
left as an exercise for the reader --- in other words, I was
identifying a potential issue and letting the audience figure out the
solution for themselves. It's a standard idiom in math textbooks...
(and, of course, if you have questions about that interoperability
issue, feel free to raise them
Thanks, I studied math not in English, that's why I didn't know :)
I made a simple tests and it seems to work nicely. However, I'm not sure
whether it will work with more complicated cases like copying, deleting, etc.
Vyacheslav
On Nov 25, 2011, at 1:15 PM, Daniel Shahaf wrote:
left as an
To clarify, the issues I was concerned about weren't with tree changes
(the level of the code dealing with content reps isn't aware of those),
but with creating/accessing a single repository sometimes via
unmodified svn 1.7.1 libraries and sometimes via forward-delta-patched
libraries.
The part I
I guess badness can happen only when accessing repositories locally (not via
svn:// or http(s)://) with patched and not patched SVN.
But usually only one version of SVN is installed on the server side, so that
should not be a big problem.
However, it's a nice exercise to check.
Vyacheslav
On Fri, Nov 25, 2011 at 01:38:44PM +0100, Vyacheslav Zholudev wrote:
I guess badness can happen only when accessing repositories locally (not
via svn:// or http(s)://) with patched and not patched SVN.
But usually only one version of SVN is installed on the server side, so that
should not
On Nov 25, 2011, at 2:02 PM, Stefan Sperling wrote:
On Fri, Nov 25, 2011 at 01:38:44PM +0100, Vyacheslav Zholudev wrote:
I guess badness can happen only when accessing repositories locally (not
via svn:// or http(s)://) with patched and not patched SVN.
But usually only one version of SVN
Hi,
how does SVN 1.7.1 store fulltext and deltas in the BDB backend? From some time
ago I remember that previous versions of SVN stored almost always a HEAD
revision as fulltext, and others as reverse deltas.(except the case when a
delta is bigger that fulltext) Was this behavior changed in
Old BDB-backed repositories stored the older revision as fulltext and
newer revisions as deltas. Repositories created with or 'svnadmin
upgrade'd by 1.6 and newer reverse this for new revisions of files
(while making sure not to introduce a dependency loop in the direction
of deltas).
13 matches
Mail list logo
