On Thu, Jul 8, 2010 at 8:35 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
>> -----Original Message-----
>> From: hyrum_at_hyrumwright.org [mailto:hyrum_at_hyrumwright.org] On Behalf Of
>> Hyrum K. Wright
>> Sent: donderdag 8 juli 2010 4:31
>> To: Bert Huijben
>> Cc: Subversion Development
>> Subject: Re: Do we better tolerate obstructed updates?
>> On Wed, Jul 7, 2010 at 1:32 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>> >> -----Original Message-----
>> >> From: hyrum_at_hyrumwright.org [mailto:hyrum_at_hyrumwright.org] On Behalf
>> >> Hyrum K. Wright
>> >> Sent: woensdag 7 juli 2010 6:03
>> >> To: Subversion Development
>> >> Subject: Do we better tolerate obstructed updates?
>> >> The bindings tests are currently failing, and there appear to be two
>> >> root causes. One of them, causing test failures in both JavaHL and
>> >> swig-rb, is that the tests expect an error with an operation that
>> >> to cause an obstruction, such as update, but those errors are no
>> >> longer being returned. Has something changed recently which allows
>> >> to better tolerate obstructions?
>> > In preparation of making this 1.6.x error into obstruction conflicts
>> > we started skipping obstructing files, recording that by adding a
>> > not-present marker in BASE_NODE (and maybe some tree conflict in some
>> > but I don't know about that part?).
>> > When we have the central db+pristine store ready we can switch to
>> > continuing the BASE_NODE update, while adding an obstruction conflict
>> > record that the in-wc file is not the real wc-file.
>> So, what is the appropriate change to the tests, which used to expect
>> an error, but which is now not thrown?
> I think it should check that a proper obstruction is notified and maybe that
> a future update brings in the new data.
Is this in the intended future behavior, or the current behavior? In
modifying the JavaHL test which is having this problem, I don't see
obstructed_update notified, only a tree conflict.
Received on 2010-07-13 15:49:33 CEST