On 06.11.2014 20:03, ivan_at_apache.org wrote:
> Author: ivan
> Date: Thu Nov 6 19:03:31 2014
> New Revision: 1637184
>
> URL: http://svn.apache.org/r1637184
> Log:
> Make FSFSv7 repositories always use consistent addressing mode, instead of
> saving revision number from which logical addressing was enabled.
Congrats on finally doing something concrete about FSFSv7.
However.
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.
> On the other hand, consistent addressing allows us to omit some tricky code.
This argument is of the same ilk as "code churn." If tricky code were a
problem, we'd never have brought Subversion to where it is now.
> This also fixes problems with long living svn_fs_t instances during the hot
> repository upgrade in background.
Which problems? You can't just say "fixes problems" without pointing
them out. As far as I can see, the hot upgrade code is pretty solid.
Furthermore, hot upgrades are a new feature in FSFSv7: So, if you have
an issue with that, by all means propose that we forbid hot upgrades, as
that will not be a regression compared to FSFSv6. Do not rip out a
completely orthogonal, important feature instead.
(I'm almost tempted to shout "veto!" but that would be less than
productive at this point.)
-- Brane
Received on 2014-11-06 20:25:08 CET