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.
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 <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