Greg Stein <gst...@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
