Re: Help on 1.6-blocker #3334 - tree conflicts in update

On Fri, Jan 30, 2009 at 5:58 PM, Paul Burba <ptburba_at_gmail.com> wrote:
> On Wed, Jan 28, 2009 at 3:48 PM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> Julian (and/or any other TCers),
>
> I've got this test working, but I'm wondering about a slightly
> different case than the one covered in the test.
>
> What if, instead of having a modification directly to the directory
> that the update will attempt to delete, we instead have a local mod
> only to a subtree of that directory? For example, say we start with
> this vanilla Greek WC:
>
> issue3334.dgb>svn st -v
> 1 1 jrandom .
> 1 1 jrandom A
> 1 1 jrandom A\B
> 1 1 jrandom A\B\lambda
> 1 1 jrandom A\B\E
> 1 1 jrandom A\B\E\alpha
> 1 1 jrandom A\B\E\beta
> 1 1 jrandom A\B\F
> 1 1 jrandom A\mu
> 1 1 jrandom A\C
> 1 1 jrandom A\D
> 1 1 jrandom A\D\gamma
> 1 1 jrandom A\D\G
> 1 1 jrandom A\D\G\pi
> 1 1 jrandom A\D\G\rho
> 1 1 jrandom A\D\G\tau
> 1 1 jrandom A\D\H
> 1 1 jrandom A\D\H\chi
> 1 1 jrandom A\D\H\omega
> 1 1 jrandom A\D\H\psi
> 1 1 jrandom iota
>
> Then we delete 'A' directly in the repos:
>
> issue3334.dgb>svn del %url53%/A -m ""
>
> Committed revision 2.
>
> Then we make a text mod in our WC to a subtree of 'A':
>
> issue3334.dgb>echo new content > A\D\G\pi
>
> issue3334.dgb>svn up
> C A
> At revision 2.
> Summary of conflicts:
> Tree conflicts: 1
>
> Ok, the tree conflict is correct, but what should be scheduled for
> addition? Should the entire subtree rooted at 'A' be schedule for
> addition as a copy from A_at_1?
>
> issue3334.dgb>svn st -v
> 2 2 pburba .
> A + C - 1 jrandom A
> > local edit, incoming delete upon update
> + - 1 jrandom A\B
> + - 1 jrandom A\B\lambda
> + - 1 jrandom A\B\E
> + - 1 jrandom A\B\E\alpha
> + - 1 jrandom A\B\E\beta
> + - 1 jrandom A\B\F
> + - 1 jrandom A\mu
> + - 1 jrandom A\C
> + - 1 jrandom A\D
> + - 1 jrandom A\D\gamma
> + - 1 jrandom A\D\G
> M + - 1 jrandom A\D\G\pi
> + - 1 jrandom A\D\G\rho
> + - 1 jrandom A\D\G\tau
> + - 1 jrandom A\D\H
> + - 1 jrandom A\D\H\chi
> + - 1 jrandom A\D\H\omega
> + - 1 jrandom A\D\H\psi
> 2 1 jrandom iota
>
> *OR* should only the modified subtree 'A/D/G/pi' and its path-wise
> ancestors be present?
>
> issue3334.dgb>svn st -v
> 2 2 pburba .
> A + C - 1 jrandom A
> > local edit, incoming delete upon update
> + - 1 jrandom A\D
> + - 1 jrandom A\D\G
> M + - 1 jrandom A\D\G\pi
>
> 2 1 jrandom iota
>
> I've got the former working*, but I wonder if the latter is not
> actually the correct behavior.

I tend to think the latter would be the correct behavior, but I am not
certain that it is so "clear-cut" that it is a must-have. My main
concern with the former behavior is that I'd not expect the final
desired result to be restoring the entire folder. I kid of see two
expected final outcomes:

1) The user wants keep their changes and the file. In which case,
they will have to do something to undo the scheduled add of all of the
other files and folders they do not want.

2) The user moves their changes to a renamed version of the file, or
abadons the change. In which case they have to revert this scheduled
add and cleanup all these files and folders. Given that they will
probably just delete the local folder "A" and all its children that is
probably not too hard.

I see scenario #1 as the problem as it would be fairly hard for the
user to fix the WC so that they could commit just the file.

I do think there is some gray area here though. So if the getting
this behavior is going to be difficult, I'd rather get the release
done and see if people run into this and think it is wrong.

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