On Fri, 2010-08-20, Greg Stein wrote:
> On Fri, Aug 20, 2010 at 10:31, <julianfoad_at_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
Received on 2010-08-20 19:46:35 CEST