On 25 November 2013 17:44, Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> wrote:
> On Mon, Nov 25, 2013 at 1:29 PM, Philip Martin <philip_at_codematters.co.uk>
>> Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> writes:
>> > On Tue, Sep 24, 2013 at 6:51 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>> >> On 23 August 2013 03:21, Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
>> >> wrote:
>> >> > Hi all,
>> >> >
>> >> > As of r1516665, work on this branch has been completed.
>> >> > Please review. See the BRANCH-README for the list of
>> >> > major changes.
>> >> >
>> >> > If there are no objections, I will merge the code in the week
>> >> > of Sep 23th.
>> >> >
>> >> Hi Stefan,
>> >> I have looked through the code but I'm not ready to put my +1 on it. I
>> >> think this branch is a good candidate for the "three +1" policy
>> >> discused some time ago.
>> > Would you vote +1 under the 3-vote policy ("seems o.k. but more
>> > independent review should take place")?
>> I've been reviewing this branch and I am now happy for it to be merged
>> to trunk.
> Thanks a lot, Philip!
> I plan on merging the branch later this week (Friday-ish).
Well, I still think that log-addressing branch should *NOT* be merged
and all FS _performance_ and format changes should be implemented in
My primary concern is that currently FSFS supports reading and writing
all FSFS formats. And there are more than 6 formats now, because they
can differ of how repositories were upgraded. This makes code very
complicated, because it should handle all different combinations of
In recent Subversion 1.8 release we got several critical data
corruption errors due this complexity and handling older formats:
* hotcopy: fix hotcopy losing revprop files in packed repos (issue #4448)
* hotcopy: cleanup unpacked revprops with '--incremental' (r1512300 et al)
* fsfs: fixed manifest file growth with revprop changes (r1513874)
* fsfs: fix packed revprops causing loss of revprops (r1513879 et al)
* fsfs: resolve endless loop problem when repos/db/uuid has \r\n (r1492145)
* fsfs: remove revision property buffer limit (r1491770)
* svnadmin upgrade: fix error of non-sharded fsfs repositories (r1494287)
* svnadmin upgrade: fix data loss when cancelling in last stage (r1494298)
>> BTW, why we are not going to implement this in the FSX only?
> Because FSX is not going to be recommended for general before
> 2017 or so.
This doesn't make sense for me: if FSX code is not ready for general
use before 2017 then we should not push FSX-like features to stable
and time proven FSFS.
CTO | VisualSVN | http://www.visualsvn.com
Received on 2013-11-27 12:20:33 CET