[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1637184 - in /subversion/trunk/subversion: libsvn_fs_fs/ tests/libsvn_fs/

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Wed, 12 Nov 2014 20:30:26 +0300

On 7 November 2014 02:44, Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> wrote:
> [This goes mostly to Ivan but the last part goes to Brane. Don't want to
> sub-thread here.]
> On Thu, Nov 6, 2014 at 8:24 PM, Branko ─îibej <brane_at_wandisco.com> wrote:
>> This is a really major functional change. I would have expected some
>> discussion on dev@ about why you think this is necessary, or even
>> useful, before you committed this. Specifically:
>> > From the performance point of view there will be no big benefits to
>> > enable
>> > log addressing for an existing repository, because the existing old part
>> > of the repository will remain to be addressed physically.
>> I disagree with your assessment. Certainly, as long as there are "live"
>> delta chains in the repository that reach all the way into
>> physically-indexed content, there will less performance benefit from
>> logical addressing than in a "pure" FSFSv7. But this state will not
>> persist "forever", certainly not for actively changed content.
>> The second problem is your assumption that dumping and loading a
>> repository is desired and/or cheap. That really depends on the size of
>> the repository (and other factors). By making a dump/load cycle
>> mandatory for upgrading a repository to log-addressing mode, you have
>> effectively killed this feature. Without any discussion, I might add.
>> The fact that logical addressing can be enabled on an existing
>> repository without requiring a costly upgrade has been one of the
>> *major* points of FSFSv7.
> I'm -.5 on removing the "mixed addressing" feature for exactly the
> points made by Brane. If it would involve massive complications
> in other parts of FSFS or otherwise require lots of additional code,
> I would be much more willing to accept that restriction.
> Right now, I only see one benefit of not having mixed mode repos:
> The txn folder does need to be renamed. That is a trivial change and
> only of interest for people writing low-level replicators. Both companies
> that I'm aware of offering those know about the change.
> Apart from that, you create the opportunity to create sharded f7
> repositories (create as f6 and immediately upgrade) that will never
> use log addressing but still gets the other format improvements.
>> > On the other hand, consistent addressing allows us to omit some tricky
>> > code.
> I completely disagree. It only removed the ~200 LOC (including
> the follow-up commit) of the TXN upgrade logic. All other changes
> are trivial. And the code in question was heavily commented. If
> there were questions / more clarification needed, I'd be happy to
> improve it. Maybe we would actually find a loophole ...
I just want to clarify my position. The mixed-adressing mode produces
a lot of new code paths related to cases when delta-chain/history
crosses the border between addressing modes (depending on which point
the repository was upgraded to the logical adressing). Almost all
tests in our test suite assume that adressing is not changing during
the tests. Most likely
we will face with unpredictable number of relatively small bugs (but
some of them will be fatal).

Anyway, the performance results says that it is not very important to
have the mixed-mode and I assume that there is currently consensus
about this.


Ivan Zhakov
Received on 2014-11-12 18:31:53 CET

This is an archived mail posted to the Subversion Dev mailing list.