Do we better tolerate obstructed updates?

["Hyrum K. Wright" <hy...@mail.utexas.edu>]

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?

-Hyrum

Re: Do we better tolerate obstructed updates?

[Stefan Sperling <st...@elego.de>]

On Tue, Jul 06, 2010 at 10:02:58PM -0600, Hyrum K. Wright wrote:
> 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?

Probably r959735?
See notes/tree-conflicts/all-add-vs-add-tree-conflicts.txt for details.

Stefan

Re: Do we better tolerate obstructed updates?

[Paul Burba <pt...@gmail.com>]

On Tue, May 10, 2011 at 5:34 AM, Neels Hofmeyr <ne...@elego.de> wrote:
> I'd like to drop a hint at
>
>  notes/tree-conflicts/all-add-vs-add-tree-conflicts.txt
>
> where I tabled up the TC cases that I changed. AFAIR it wasn't quite
> where I wanted it when my activity faded, so unless others have covered
> the ':(' cases, they are IMHO still inconsistent.
>
> I did what I did because there was wishful thinking whispering from the
> bushes, in want of actively marking obstructed items so that they show
> up as conflicts to be resolved, to warn at commit time etc.. I agree(d)
> that obstructions are half like tree-conflicts, but also half unlike
> tree conflicts. I figured: here we have a conflict marker thing (TC)
> that blocks commits, so I'll try to use that until someone makes a
> proper conflict marker specifically for obstructions... Then I got
> carried away and added hacky auto-resolution in case of tree conflicts
> on obstructions, and AFAIR that was removed again. I'm quite content
> with that.
>
> (I hope I'm not confusing anyone, my remark may be off at a tangent...)
>
> ~Neels

Hi Neels,

Thanks for the reply.  My concern here is limited to issue #3680,
which was[1] a blocker for 1.7.  That issue was limited to the
question of whether we should consider *unversioned* obstructions as
tree-conflicts or not.  So regarding
all-add-vs-add-tree-conflicts.txt, the only scenario I was interested
in was the unversioned obstructions, and those are all consistent: We
raise a tree-conflict.  Possibly some of the other scenarios described
there should block 1.7, but that is a separate discussion.

Right now we have two binding tests simply commented out[2], awaiting
resolution on a closed issue.  I think the new behavior is acceptable,
but is there consensus on this?  Does anybody want to return to the
old behavior or implement some third option.

Paul

[1] "was" because Mike marked it as invalid because it was an open
design question, not a bug per se,
http://subversion.tigris.org/issues/show_bug.cgi?id=3680#desc5

[2] http://svn.apache.org/viewvc?view=revision&revision=963726
     http://svn.apache.org/viewvc?view=revision&revision=963734

> On Mon, 2011-05-09 at 14:34 -0400, Paul Burba wrote:
>> On Tue, Jul 13, 2010 at 10:19 AM, Stefan Sperling <st...@elego.de> wrote:
>> > On Tue, Jul 13, 2010 at 03:07:30PM +0100, Hyrum K. Wright wrote:
>> >> Could you file the issue?
>> >
>> > Sure: http://subversion.tigris.org/issues/show_bug.cgi?id=3680
>>
>> Hi All,
>>
>> So how do we resolve this issue?  The crux seems to be:
>>
>>   In r959735, some obstruction cases were changed to cause tree conflicts,
>>   resulting in failing tests in the JavaHL bindings. It's unclear whether the
>>   test's expectations should be changed, or whether flagging tree conflicts on
>>   obstructions is what we want to do.
>>
>> It's true that with Neels' changes in r959735 we had some
>> inconsistencies with how unversioned obstructions were handled, but
>> with his subsequent change in r965912 we are now consistent: An
>> incoming add of a [file|dir|symlink] onto an unversioned
>> [file|dir|symlink] is now always a tree conflict.
>>
>> This seems preferable to the 1.6. behavior where we simply stopped
>> with an error (potentially mid-may through the update) as soon as an
>> add was attempted with an unversioned obstruction.
>>
>> Are there some wcng subtleties that have not been discussed in this
>> thread or in the issue?
>>
>> Paul
>
>
>

Re: Do we better tolerate obstructed updates?

[Neels Hofmeyr <ne...@elego.de>]

I'd like to drop a hint at

  notes/tree-conflicts/all-add-vs-add-tree-conflicts.txt

where I tabled up the TC cases that I changed. AFAIR it wasn't quite
where I wanted it when my activity faded, so unless others have covered
the ':(' cases, they are IMHO still inconsistent.

I did what I did because there was wishful thinking whispering from the
bushes, in want of actively marking obstructed items so that they show
up as conflicts to be resolved, to warn at commit time etc.. I agree(d)
that obstructions are half like tree-conflicts, but also half unlike
tree conflicts. I figured: here we have a conflict marker thing (TC)
that blocks commits, so I'll try to use that until someone makes a
proper conflict marker specifically for obstructions... Then I got
carried away and added hacky auto-resolution in case of tree conflicts
on obstructions, and AFAIR that was removed again. I'm quite content
with that.

(I hope I'm not confusing anyone, my remark may be off at a tangent...)

~Neels

On Mon, 2011-05-09 at 14:34 -0400, Paul Burba wrote:
> On Tue, Jul 13, 2010 at 10:19 AM, Stefan Sperling <st...@elego.de> wrote:
> > On Tue, Jul 13, 2010 at 03:07:30PM +0100, Hyrum K. Wright wrote:
> >> Could you file the issue?
> >
> > Sure: http://subversion.tigris.org/issues/show_bug.cgi?id=3680
> 
> Hi All,
> 
> So how do we resolve this issue?  The crux seems to be:
> 
>   In r959735, some obstruction cases were changed to cause tree conflicts,
>   resulting in failing tests in the JavaHL bindings. It's unclear whether the
>   test's expectations should be changed, or whether flagging tree conflicts on
>   obstructions is what we want to do.
> 
> It's true that with Neels' changes in r959735 we had some
> inconsistencies with how unversioned obstructions were handled, but
> with his subsequent change in r965912 we are now consistent: An
> incoming add of a [file|dir|symlink] onto an unversioned
> [file|dir|symlink] is now always a tree conflict.
> 
> This seems preferable to the 1.6. behavior where we simply stopped
> with an error (potentially mid-may through the update) as soon as an
> add was attempted with an unversioned obstruction.
> 
> Are there some wcng subtleties that have not been discussed in this
> thread or in the issue?
> 
> Paul

Re: Do we better tolerate obstructed updates?

[Paul Burba <pt...@gmail.com>]

On Tue, Jul 13, 2010 at 10:19 AM, Stefan Sperling <st...@elego.de> wrote:
> On Tue, Jul 13, 2010 at 03:07:30PM +0100, Hyrum K. Wright wrote:
>> Could you file the issue?
>
> Sure: http://subversion.tigris.org/issues/show_bug.cgi?id=3680

Hi All,

So how do we resolve this issue?  The crux seems to be:

  In r959735, some obstruction cases were changed to cause tree conflicts,
  resulting in failing tests in the JavaHL bindings. It's unclear whether the
  test's expectations should be changed, or whether flagging tree conflicts on
  obstructions is what we want to do.

It's true that with Neels' changes in r959735 we had some
inconsistencies with how unversioned obstructions were handled, but
with his subsequent change in r965912 we are now consistent: An
incoming add of a [file|dir|symlink] onto an unversioned
[file|dir|symlink] is now always a tree conflict.

This seems preferable to the 1.6. behavior where we simply stopped
with an error (potentially mid-may through the update) as soon as an
add was attempted with an unversioned obstruction.

Are there some wcng subtleties that have not been discussed in this
thread or in the issue?

Paul

Re: Do we better tolerate obstructed updates?

["Hyrum K. Wright" <hy...@mail.utexas.edu>]

On Tue, Jul 13, 2010 at 3:19 PM, Stefan Sperling <st...@elego.de> wrote:
> On Tue, Jul 13, 2010 at 03:07:30PM +0100, Hyrum K. Wright wrote:
>> Could you file the issue?
>
> Sure: http://subversion.tigris.org/issues/show_bug.cgi?id=3680
>

Thanks.  I've commented out the failing tests (swig-rb and JavaHL lack
a XFail directive), and noted them and the relevant revisions in the
issue tracker.

-Hyrum

Re: Do we better tolerate obstructed updates?

[Stefan Sperling <st...@elego.de>]

On Tue, Jul 13, 2010 at 03:07:30PM +0100, Hyrum K. Wright wrote:
> Could you file the issue?

Sure: http://subversion.tigris.org/issues/show_bug.cgi?id=3680

Re: Do we better tolerate obstructed updates?

["Hyrum K. Wright" <hy...@mail.utexas.edu>]

On Tue, Jul 13, 2010 at 2:57 PM, Stefan Sperling <st...@elego.de> wrote:
> On Tue, Jul 13, 2010 at 02:48:52PM +0100, Hyrum K. Wright wrote:
>> On Thu, Jul 8, 2010 at 8:35 AM, Bert Huijben <be...@qqmail.nl> wrote:
>> > 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.
>
> I think Neels changed the behaviour to flagging a tree conflict in r959735.
> I am not sure if that is what we want. AFAIK we had decided long ago to not
> treat obstructions as conflicts. But maybe we don't all agree on that?
>
> I'd say mark the text XFail for now, and file an issue with milestone
> 1.7.0 prompting ourselves to make up our minds about this.

Could you file the issue?  I'm not very current on the issues (as you
seem to be); I'm just trying to avoid spurious test failures.  I'll
have happy to mark the tests XFail and reference them in the issue,
though.

-Hyrum

Re: Do we better tolerate obstructed updates?

[Stefan Sperling <st...@elego.de>]

On Tue, Jul 13, 2010 at 02:48:52PM +0100, Hyrum K. Wright wrote:
> On Thu, Jul 8, 2010 at 8:35 AM, Bert Huijben <be...@qqmail.nl> wrote:
> > 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.

I think Neels changed the behaviour to flagging a tree conflict in r959735.
I am not sure if that is what we want. AFAIK we had decided long ago to not
treat obstructions as conflicts. But maybe we don't all agree on that?

I'd say mark the text XFail for now, and file an issue with milestone
1.7.0 prompting ourselves to make up our minds about this.

Stefan

Re: Do we better tolerate obstructed updates?

["Hyrum K. Wright" <hy...@mail.utexas.edu>]

On Thu, Jul 8, 2010 at 8:35 AM, Bert Huijben <be...@qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: hyrum@hyrumwright.org [mailto:hyrum@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 <be...@qqmail.nl> wrote:
>> >> -----Original Message-----
>> >> From: hyrum@hyrumwright.org [mailto:hyrum@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.

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.

-Hyrum

RE: Do we better tolerate obstructed updates?

[Bert Huijben <be...@qqmail.nl>]

> -----Original Message-----
> From: hyrum@hyrumwright.org [mailto:hyrum@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 <be...@qqmail.nl> wrote:
> >> -----Original Message-----
> >> From: hyrum@hyrumwright.org [mailto:hyrum@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

Re: Do we better tolerate obstructed updates?

["Hyrum K. Wright" <hy...@mail.utexas.edu>]

On Wed, Jul 7, 2010 at 1:32 PM, Bert Huijben <be...@qqmail.nl> wrote:
>> -----Original Message-----
>> From: hyrum@hyrumwright.org [mailto:hyrum@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?

-Hyrum

RE: Do we better tolerate obstructed updates?

[Bert Huijben <be...@qqmail.nl>]

> -----Original Message-----
> From: hyrum@hyrumwright.org [mailto:hyrum@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.


	Bert
> 
> -Hyrum