Greg Stein <gstein_at_gmail.com> writes:
> I completely disagree with this.
> Didn't I just get done describing the intent here?
You didn't respond to my questions in the last thread.
> We allow the
> upgrade to continue. If there is an impact on work queue items, then
> they must be upgraded, too.
We don't generally support running old workqueues with newer code, so
why is uprade so different? Take this recent commit:
it removes SVN_WC__LOG_DELETE_LOCK. Every time we remove one of the
log actions we effectively broke any workqueue that included them.
Nobody has written any code to migrate those workqueues.
> Clients are not expected to back up to previous revisions and run "svn
> cleanup". We ONLY plan to require that for the 1.6 -> 1.7 transition.
>>From then on, we can/should/will perform an upgrade with a non-empty
> work queue. Every single auto-upgrade in the past has operated in this
> fashion, and we will continue to do so from 1.7 onwards.
> Please revert. This is contrary to the design that I explained just
Why is it so important to support this? It doesn't affect many people
but writing the code to upgrade log items is a big effort. And it's
not code that will get used by anyone other than people running dev
code. It will be poorly tested and a maintenance burden. How long do
we keep it? How far back in wcng history do we support?
Take this workqueue item:
13|(loggy 30 /home/pm/sw/subversion/obj/wc1 68 <mv
It will break the working copy on upgrade because the wrong text-base
will get copied into the pristine store. When we upgrade and run the
workqueue it will probably fail because the .svn/text-base no longer
exists. How will the user handle that? Isn't it better to get an
error saying "cleanup first"?
That's just one example. I don't know exactly which workqueue items
break. SVN_WC__LOG_CP_AND_TRANSLATE probably breaks. There could be
ones that are no longer in log.c that break, as well as non-loggy
Received on 2010-06-30 19:55:47 CEST