Re: issue 3899 (copying conflict victims)

On May 27, 2011, at 15:23 , Julian Foad wrote:

>
> To start simply, I consider a file rather than a directory, on update.
> The only relevant tree conflicts are those involving a local file that
> exists (because we're talking about copying or moving it), so that's
> delete-onto-edited or add-onto-added. Afterwards I'll look at merge,
> where more combinations are possible.
>
>
> * File 'foo': tree conflict on update, incoming delete, local edit:
>
> The default resolution ('mine') is to accept the working version of
> 'foo', which has been automatically re-scheduled as copy-from
> foo_at_OLDREV.

On a side note, when you say "working version", are you referring to the
ACTUAL tree (including local text edits, prop edits, changelists)?

I'm not really up to date on the WC-NG terms. Should we say ACTUAL,
implying WORKING, or do we have to say WORKING+ACTUAL? The
second form sounds a bit redundant.

And should one say "actual tree", without SHOUTING? :-)

> But let's say I intend to accept the incoming delete, but I
> first want to preserve my edited version under version control under a
> different filename, and may want to commit it later. So I either "copy"
> or "move" the file to a new name.
>
> - If I copy the working version of 'foo' to 'bar', I don't expect
> 'bar' to be tree-conflicted; it wouldn't make sense because it is a new
> object (although copied from foo_at_OLDREV). The tree conflict must remain
> on 'foo', and I can resolve it there.
>
> - If I move the working version of 'foo' to 'bar', it's a bit
> different. Supposing we support "true renames" in the WC, then I would
> expect "svn info bar" and "svn resolve bar" to access the tree conflict
> on "the node that is currently at working path 'bar' but was at path
> 'bar' in the base tree". Some might argue that that is too much of a
> conceptual incompatibility with current svn, and might demand that the
> user still access 'foo' and 'bar' separately. But if instead I moved
> the parent directory that contains 'foo', then I would feel more
> strongly that I should be addressing the working path only by its new
> name 'parent2/foo'. At the same time, after either one of these moves,
> the update editor still needs to see that the base path 'parent/foo' is
> a tree conflict victim. So (if we support true renames on the client)
> the tree conflict should be logically attached to the versioned node
> that is being moved, not just to its base path or its working path. In
> implementation terms, the best fit for the current WC DB design would be
> to keep the conflict info at the working path, and thus move it whenever
> we move the working node.
>
> - Given that we don't support true renames, I think for now we
> should treat "move" the same as "copy plus delete".

I agree. Maybe we can make a finer distinction in the future, if the working
copy ever includes a "move" operation.

>
>
> * File 'foo': tree conflict on update, incoming add, local add:
>
> I think this would have the same conclusions as above, but I haven't
> gone through this scenario in detail.

This seems to be the only kind of tree conflict upon update where BASE isn't
shadow-updated. I'm not sure why it isn't. We should investigate. Are there
any other situations where BASE is incompletely updated?

>
>
> * File 'foo': tree conflict on merge, incoming delete, local edit;
> * File 'foo': tree conflict on merge, incoming add, local add:
>
> Should a tree conflict on merge behave the same way as on update?
>
> One difference that doesn't matter but often confuses me is that an
> update (or switch) primarily applies the incoming change to the base
> tree, and secondarily to the working tree, whereas a merge applies the
> incoming change only to the working tree. In a merge, a tree conflict
> can only arise on the working tree. In an update the base tree is
> always in the expected state, by definition, so again a tree conflict
> can only arise on the working tree.
>
> Because the target of the merge is purely the working tree in the
> WC, I feel that if I move the conflict victim or a parent directory of
> it, then Subversion should move the conflict (info) with it. But if I
> copy it, then it should definitely not copy the conflict.
>
> ====
>
> If all of the above makes sense (a big "if"), the conclusion would be
> that a tree conflict on update (or switch) should stay where it was and
> not be copied, whereas a tree conflict on merge should stay where it was
> unless the copying is part of a move in which case it should be moved.
> But that seems a bit inconsistent. I can't quite see yet a simple
> consistent model for sensible behaviour.
>
> And just a thought about one way to partition the implementation:
>
> * The WC layer never copies tree conflict info when doing a copy
> (including a copy that is half of a move).

I'm starting with this part of the solution, in the client library. I believe a
fix at the WC-layer won't work, because svn_client_move6() ends up
calling the following functions:

  svn_wc_copy3() <--- with metadata_only == TRUE
  svn_io_file_rename() <--- possibly including conflict-marker files
  svn_wc_delete4()

I think it'll be easier to resolve the conflicts by calling
svn_wc_resolved_conflict5() after both copy steps are complete.

>
> * The client layer "move" and "copy" commands move the conflict info
> according to the rules that we decide, e.g. iff it's a tree conflict "on
> merge", then it reads and deletes all the tree conflict info from the
> source tree and writes it to the destination tree.
>
>> [...] If I copy the (local, working) file to another name or to
>> another directory, the tree conflict (info) should not be copied; just
>> the current working version of the file should be copied.
>> If I delete the file, strictly speaking the tree conflict (info)
>> should remain, although, as a high-level convenience, we might want to
>> automatically resolve the conflict at the same time.
>> If I move the file, the tree conflict (info) should stay where it was.

I'll start by implementing the automatic conflict resolution on copy
destinations. Then we can tackle the move-destinations.

Steve

--
Stephen Butler | Senior Consultant
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
tel: +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