On Fri, 2010-08-20, Greg Stein wrote: > On Fri, Aug 20, 2010 at 10:31, <julianf...@apache.org> wrote: > > +++ subversion/trunk/subversion/libsvn_wc/upgrade.c Fri Aug 20 14:31:27 2010 > > @@ -1420,9 +1420,7 @@ svn_wc__upgrade_sdb(int *result_format, > > /* ### TODO: Either upgrade to single-DB format here, or quit > > * at format 18 and ask the user to run the external script > > * 'tools/dev/wc-ng/bump-to-19.py'. */ > > When you first checked in the script, I assumed you were doing that > for rapid dev/test. There is no way that I would ever support an > external script to perform this upgrade.
Wasn't sure yet how it's going to work out. The script is to get us going while we figure out how to do the 'proper' 1.6-to-1.7 upgrade. Of course that won't require an external script. This script is just for us devs to upgrade our format-18 WCs to format-19. It sounds like you are saying this incremental step must be implemented in line. Is that because the sequence of incremental steps as implemented in svn_wc__upgrade_sdb() needs to be the same sequence that is used by the final 1.6-to-1.7 upgrade? I was thinking we might want to implement the final 1.6-to-1.7 upgrade as a direct migration from scattered entries files into a single DB. That would be potentially be considerably faster and less susceptible to losing information along the way due to the complexities of multiple intermediate states. (Such as what we can't represent accurately until NODE_DATA, for example.) If the DB access functions can be made sufficiently agnostic of DB location, that should be possible. On the other hand, there may be reasons of complexity why we should not attempt to write a bypass, and there may be reasons of testability. I'm not sure about that. If so, then of course we'll implement this step as an in-line auto-upgrade step and expect it to be called as part of the final 1.6-to-1.7 upgrade sequence. What are your thoughts? - Julian
