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 left to the readers was determining whther or not Badness
will happen in the event of such "mixed" access.
Vyacheslav Zholudev wrote on Fri, Nov 25, 2011 at 13:20:55 +0100:
> 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 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 on this list.)
> >
> > Vyacheslav Zholudev wrote on Fri, Nov 25, 2011 at 13:07:52 +0100:
> >> 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 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 Zholudev wrote on Fri, Nov 25, 2011 at 12:04:22 +0100:
> >>>> 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 Nov 25, 2011, at 11:59 AM, Daniel Shahaf wrote:
> >>>>
> >>>>> 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 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 them (unless the delta would save no space compared to the
> >>>>>> fulltext).
> >>>>>> "
> >>>>>> My own experiments with SVN 1.4 code confirm that.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> 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://subversion.apache.org/docs/release-notes/1.6#bdb-forward-deltas
> >>>>>>>
> >>>>>>> On Friday, November 25, 2011 1:08 AM, "Vyacheslav Zholudev" <vyacheslav.zholudev_at_gmail.com> wrote:
> >>>>>>>> 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 SVN 1.7? I've looked at the notes about BDB and they don't differ almost at all from SVN 1.4's ones. Of course, I could look into the code more carefully, but my hope was that it wouldn't be a big deal to give me a short answer, if possible.
> >>>>>>>>
> >>>>>>>> Thanks in advance!
> >>>>>>>>
> >>>>>>>> Best,
> >>>>>>>> Vyacheslav
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
>
Received on 2011-11-25 13:30:28 CET