Re: svn commit: r959257 - /subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c

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:

 http://svn.apache.org/viewvc?rev=959374&view=rev

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
> yesterday.

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
   dest=".svn/text-base/f.svn-base"
   name=".svn/svn-ZIxV3z"/>
)

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
ones.

-- 
Philip