[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: Paul Burba <ptburba_at_gmail.com>
Date: Wed, 11 May 2011 17:33:38 -0400

On Tue, May 10, 2011 at 5:34 AM, Neels Hofmeyr <neels_at_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.


[1] "was" because Mike marked it as invalid because it was an open
design question, not a bug per se,

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

> On Mon, 2011-05-09 at 14:34 -0400, Paul Burba wrote:
>> On Tue, Jul 13, 2010 at 10:19 AM, Stefan Sperling <stsp_at_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
Received on 2011-05-11 23:34:05 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.