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.zholu...@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 > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >> >
