Quoting Mark Phippard <markphip_at_gmail.com>:
> 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.
+1
>
> So I would be OK with this coming post 1.6 if it requires a lot of
> work and verification.
I think it will require a fair bit of work, because the locally-
added tree shouldn't be overwritten without checking for text and
prop conflicts. (Details inline below)
>
> 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.
Actually, an update's incoming text and prop changes are merged
into a locally-added-without-history tree, possibly raising text
and prop conflicts.
Currently, when we raise a tree conflict, we do one of the
following to the local content:
(local del, incoming edit):
Replace the local content without further conflict-checking,
because the user already scheduled it for deletion.
(local add-w-hist, incoming add):
Skip the local victim tree entirely.
(Note: Other types of tree conflicts have no incoming adds or
edits, so content merging isn't an issue.)
Case A above (local add-wo-hist, incoming add):
I assume we want to keep the content merging. If so...we'll
have to overhaul the notification code to integrate tree
conflict notification into the normal close_{directory,file}
notification. Funny thing is, last fall we had it that way,
until we decided in a moment of temporary insanity to skip all
TC victims. :-) Rearranging the notification code is about
a thousand-line diff, IIRC, which is perhaps more than we
want to tackle before 1.6.0.
>>
>> 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.
Since we'd print the tree conflict notification when closing the
victim, we could hold off actually writing the tree conflict
description until the close, and write it only if there are text
or property conflicts in the tree. Or, to be strict, if the local
and incoming trees didn't match exactly.
Regards,
Steve
--
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
Received on 2009-02-13 18:14:57 CET