[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Do we better tolerate obstructed updates?

From: Bert Huijben <bert_at_qqmail.nl>
Date: Thu, 8 Jul 2010 09:35:35 +0200

> -----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
> Of
> >> 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
> used
> >> to cause an obstruction, such as update, but those errors are no
> >> longer being returned.  Has something changed recently which allows
> us
> >> to better tolerate obstructions?
> >
> > In preparation of making this 1.6.x error into obstruction conflicts
> later,
> > we started skipping obstructing files, recording that by adding a
> > not-present marker in BASE_NODE (and maybe some tree conflict in some
> cases,
> > but I don't know about that part?).
> >
> > When we have the central db+pristine store ready we can switch to
> just
> > continuing the BASE_NODE update, while adding an obstruction conflict
> to
> > 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.

        Bert
Received on 2010-07-08 09:36:18 CEST

This is an archived mail posted to the Subversion Dev mailing list.