Dood. Re-read my email. I said interim wq items do not have to be supported.
Only 1.7 [release] items.
On Jul 1, 2010 5:08 AM, "Philip Martin" <philip.martin_at_wandisco.com> wrote:
Greg Stein <gstein_at_gmail.com> writes:
> On Wed, Jun 30, 2010 at 13:55, Philip Martin <philip.martin...
I realise that. You seemed to be accusing me of ignoring you, and I
was pointing out that I didn't ignore you it's just that I don't agree
with you. Sorry if it came across the wrong way.
>>> We allow the
>>> upgrade to continue. If there is an impact on work queue items, then
>>> they ...
For devs it's better not to autoupgrade. Then they can revert to the
version that generated the workqueue and use that. If we autoupgrade
they have no usable version.
> BUT: the need-clean-wq-for-upgrade is NOT true moving forward from 1.7.
>
>>> Clients are not exp...
I don't see the difference. At some point you have to write the code
to do it.
> The process that I
> encoded in the db-opening logic was to support THAT purpose.
>
>> not code t...
But your plan is that at release we should be capable of handling that
old workqueue item? This is a workqueue item only ever produced by a
dev version. I'd argue that these pre-1.7 dev workqueues don't need
to be supported long-term. You realise that the XML parser in log.c
would have to be retained, probably including bits that have already
been deleted? And that parser would never be used by people upgrading
from 1.6, since they have to cleanup first.
>> When we upgrade and run the
>> workqueue it will probably fail because the .svn/text-base no lo...
After we release 1.7 it's different. We can choose to autoupgrade, or
we can treat it like 1.6 and say that an upgrade step is required.
It's hard to predict the future. If 1.8 uses a totally different
backend for the wc then while we would support upgrading from a 1.7 wc
we might not support running 1.7 workqueues.
>> That's just one example. I don't know exactly which workqueue items
>> break. SVN_WC__LOG_CP_A...
I'd argue that's unneccesary, it's a maintenance burden we don't need.
Is there a regression test? Does it still work? However it's trivial
compared to supporting an XML parser that's not otherwise required.
> Another approach is to rename the work item in the OP_FOO symbols.
> Stale items become obvious w...
I still disagree. Having made the decision to introduce an upgrade
step for 1.6-to-1.7 we should take full advantage of that. The
intermediate pre-1.7 workqueues do not need to be supported. Then we
can throw out all the log parsing code.
--
Philip
Received on 2010-07-01 14:21:02 CEST