On Tue, May 10, 2011 at 5:34 AM, Neels Hofmeyr <neels_at_elego.de> wrote:
> I'd like to drop a hint at
> 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...)
Thanks for the reply. My concern here is limited to issue #3680,
which was 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, 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.
 "was" because Mike marked it as invalid because it was an open
design question, not a bug per se,
> 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?
Received on 2011-05-11 23:34:05 CEST