subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@wandisco.com>
Subject Re: svn commit: r1637184 - in /subversion/trunk/subversion: libsvn_fs_fs/ tests/libsvn_fs/
Date Thu, 06 Nov 2014 19:24:36 GMT
On 06.11.2014 20:03, ivan@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

Mime
View raw message