Re: Tree conflict merry-go-round on update/switch

Stephen Butler wrote:
> Quoting Stephen Butler <sbutler_at_elego.de>:
>
>> Hi tree conflict fans,
>>
>> I had another look at Mark Phippard's experiment with creating
>> a tree conflict during update (local edit, incoming delete,
>> aka use case 2). That's a tricky one to recover from.
>>
>> Mark's original mail is here:
>>
>> <http://svn.haxx.se/dev/archive-2008-10/1090.shtml>
>>
>> If we skip the update of the victim, to be consistent with
>> other tree conflicts, then the user has to resolve the conflict
>> and update again before (optionally) re-adding the victim and
>> committing the local changes.
>>
>> I fixed some of the problems that Mark noticed, but not all.
>> There is a blocker in that the "update again" step creates a
>> fresh tree conflict. Doh!
>
>
> (replying to myself ;)
>
> The fresh tree conflict is not exactly wrong, because the existence of
> the local mods means that the tree conflict still exists "on the
> ground".
>
> A user workaround is to
>
> 1. non-svn-move the modified victim elsewhere

I usually prefer to create a diff and re-apply it later. That also avoids
problems with deeply nested changes and the .svn directories. Can a diff
still see the canges on a conflicted item, always?

(assuming that we're not implementing pulling in of tree-conflict changes in
1.6, as in my previous post just this minute, we still need to work this out
for 1.6)

~Neels

>
> 2. resolve the victim
>
> 3. update (deleting the victim & descendants)
>
> 4. copy the old victim back into the wc
>
> 5. non-svn-move the modified victim back, overwriting the old
> version
>
> This is awkward for directory victims, which take .svn dirs with
> them. The user should run svn export to extract unversioned items.
>
> Fixing this issue would allow the user to
>
> 1. resolve the victim
>
> 2. update (deleting the victim & descendants, leaving local mods
> unversioned)
>
> 3. non-svn-move the local mods elsewhere
>
> 4. copy the old victim back into the wc
>
> 5. non-svn-move the unversion local mods back, overwriting the old
> version
>
> Because svn copy doesn't support a --force option like update and
> switch do, the use has to move the modified victim manually before
> copying the older version into the working copy. At least, it's
> easier this way, moving a nonversioned victim.
>
> Comparing the two workarounds above, the difference isn't as stark as
> I first expected. I suppose svn copy --force would be nice to have.
>
> Fixing this issue would require changing the data structures in the
> working copy library, and changing the behavior of commands that
> create and read tree conflicts. Is that allowed after branching 1.6?
>
> Steve
>
>>
>> An obvious solution is to record the tree conflict as resolved
>> with regard to the incoming version. At a minimum, we need to
>> record the incoming svn_wc_conflict_version_t; if an update or
>> switch to the same URL_at_REV occurs, it will remove the resolved-
>> version data and not create a tree conflict. An update/switch
>> to a different URL_at_REV would create a new tree conflict.
>>
>> An alternative design is to add a boolean "resolved" field to
>> the existing svn_wc_conflict_description_t. The resolve[d]
>> commands would leave the tree conflict data in place, to be
>> removed by update/switch to the same URL_at_REV. An update/switch
>> to a different URL_at_REV would create a new tree conflict with
>> resolved=FALSE.
>>
>> A third alternative is simply to not include update/switch tree
>> conflicts in 1.6.
>>
>> Comments, anyone?
>>
>> Steve
>
>