On 06.11.2014 20:03, i...@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
