Re: Need to resolve expected behavior of XFailing tests caused by tree conflicts (Issue #3209)

I am going to top-reply because it is a "meta comment".

This came up as we were working on resolutions for various tree
conflicts. It just did not feel to us like it was explainable why
this was not a tree conflict. The situation seems similar to lots of
the other scenarios where TC's are raised. So ideally, for
consistency with ourselves, yes, I think this should be a tree
conflict.

That said, now that we have a tree conflicts mechanism in place, I
have no problem with shipping a release that has scenarios where we
are not currently raising tree conflicts, but would like to. IOW, we
can still improve out detection mechanisms post-1.6. The main thing
of course, is that in all scenarios we must leavesthe WC in a usable
state. In this case, I do think the current behavior does do that.

So I would be OK with this coming post 1.6 if it requires a lot of
work and verification.

Mark

PS - I agree that "ideally" if the file contents are identical, we
would not raise a conflict and just convert the local Add into a local
"Normal" state file. I do not see any reason to raise a conflict in
this scenario if it is possible.

On Fri, Feb 13, 2009 at 10:49 AM, Paul Burba <ptburba_at_gmail.com> wrote:
> I think we need to change this. Last night in IRC Mark raised this
> very issue, specifically the case where a file add is obstructed by a
> file added without history where the files have text conflicts. He
> expected a tree conflict in this case. Prior to merging the issue
> 3334 branch to trunk we did get a tree conflict(1):
>
> PRE3334.DBG>svn st -v update_tests-34.backup\A\D
> 1 1 jrandom update_tests-34.backup\A\D
> 1 1 jrandom update_tests-34.backup\A\D\gamma
> 1 1 jrandom update_tests-34.backup\A\D\G
> 1 1 jrandom update_tests-34.backup\A\D\G\pi
> 1 1 jrandom update_tests-34.backup\A\D\G\rho
> 1 1 jrandom update_tests-34.backup\A\D\G\tau
> 1 1 jrandom update_tests-34.backup\A\D\H
> 1 1 jrandom update_tests-34.backup\A\D\H\chi
> 1 1 jrandom update_tests-34.backup\A\D\H\omega
> 1 1 jrandom update_tests-34.backup\A\D\H\psi
> A 0 ? ? update_tests-34.backup\A\D\epsilon
>
> PRE3334.DBG>svn log -r2 -v -q update_tests-34.backup
> ------------------------------------------------------------------------
> r2 | jrandom | 2009-02-13 09:47:36 -0500 (Fri, 13 Feb 2009)
> Changed paths:
> A /A/D/epsilon
> ------------------------------------------------------------------------
>
> PRE3334.DBG>svn up update_tests-34.backup\A\D
> C update_tests-34.backup\A\D\epsilon
> At revision 2.
> Summary of conflicts:
> Tree conflicts: 1
>
> ===CASE A===
>
> With trunk_at_35842, as you point out, there is no tree conflict nor any error:
>
> trunk.dbg>svn up update_tests-34.backup\A\D
> Conflict discovered in 'update_tests-34.backup/A/D/epsilon'.
> Select: (p) postpone, (df) diff-full, (e) edit,
> (mc) mine-conflict, (tc) theirs-conflict,
> (s) show all options: p
> C update_tests-34.backup\A\D\epsilon
> Updated to revision 2.
> Summary of conflicts:
> Text conflicts: 1
>
> trunk.dbg>svn st -v update_tests-34.backup\A\D
> 2 2 jrandom update_tests-34.backup\A\D
> ? update_tests-34.backup\A\D\epsilon.mine
> ? update_tests-34.backup\A\D\epsilon.r0
> ? update_tests-34.backup\A\D\epsilon.r2
> 2 1 jrandom update_tests-34.backup\A\D\gamma
> 2 1 jrandom update_tests-34.backup\A\D\G
> 2 1 jrandom update_tests-34.backup\A\D\G\pi
> 2 1 jrandom update_tests-34.backup\A\D\G\rho
> 2 1 jrandom update_tests-34.backup\A\D\G\tau
> 2 1 jrandom update_tests-34.backup\A\D\H
> 2 1 jrandom update_tests-34.backup\A\D\H\chi
> 2 1 jrandom update_tests-34.backup\A\D\H\omega
> 2 1 jrandom update_tests-34.backup\A\D\H\psi
> C 2 2 jrandom update_tests-34.backup\A\D\epsilon
>
> ===CASE B===
>
> If there are no text differences between the two files then we report
> the added obstruction as 'E'xisting:
>
> trunk.dbg>svn up update_tests-34.backup\A\D
> E update_tests-34.backup\A\D\epsilon
> Updated to revision 2.
>
> trunk.dbg>svn st -v update_tests-34.backup\A\D
> 2 2 jrandom update_tests-34.backup\A\D
> 2 1 jrandom update_tests-34.backup\A\D\gamma
> 2 1 jrandom update_tests-34.backup\A\D\G
> 2 1 jrandom update_tests-34.backup\A\D\G\pi
> 2 1 jrandom update_tests-34.backup\A\D\G\rho
> 2 1 jrandom update_tests-34.backup\A\D\G\tau
> 2 1 jrandom update_tests-34.backup\A\D\H
> 2 1 jrandom update_tests-34.backup\A\D\H\chi
> 2 1 jrandom update_tests-34.backup\A\D\H\omega
> 2 1 jrandom update_tests-34.backup\A\D\H\psi
> 2 2 jrandom update_tests-34.backup\A\D\epsilon
>
> I agree with Mark that CASE A should be a tree conflict, and the
> incoming file's text should simply be replaced by the locally added
> file's text rather than being merged. This essentially maintains the
> old obstruction tolerance functionality added in r22257 but adds a
> tree conflict to attract the user's attention that something might be
> amiss.
>
> It's a bit trickier with case B, the existing behavior of not raising
> a tree conflict is quite nice, but at first glance this does not
> appear very straightforward...looking a bit deeper right now.
>
> Does this sound like a reasonable approach?
>
> Paul
>
> ~~~~~
>
> (1) Before the 3334 branch was merged back to trunk things didn't work
> quite so well:
>
> Turns out epsilon is still scheduled for addition, and a revert or
> resolve shows it as unversioned!
>
> PRE3334.DBG>svn st -v update_tests-34.backup\A\D\epsilon
> A C 0 ? ? update_tests-34.backup\A\D\epsilon
> > local add, incoming add upon update
>
> PRE3334.DBG>svn revert -R update_tests-34.backup\A\D\epsilon
> Reverted 'update_tests-34.backup\A\D\epsilon'
>
> PRE3334.DBG>svn st -v update_tests-34.backup\A\D\epsilon
> ? update_tests-34.backup\A\D\epsilon
>
>
> PRE3334.DBG>
>

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1151646