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
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
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
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
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
"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 the
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
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
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
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.
>
> 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 "delta"s
against
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).
http://subv
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 S
13 matches
Mail list logo