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