Stephen Butler wrote:
> On May 26, 2011, at 17:56 , Philip Martin wrote:
> > Julian Foad <julian.foad_at_wandisco.com> writes:
> >
> >> I am not saying there are no problems with such copies/moves, just I
> >> don't see a problem with the conflict-source info.
> >
> > Issue 3899 is not about repository locations but about the
> > left/right/mine files in ACTUAL_NODE.
[...]
> > Now copy A to B:
> >
> > $ sqlite3 wc/.svn/wc.db "select * from actual_node"
> > 1|A/f|A||A/f.r2|A/f.r7|A/f.mine||||||||
> > 1|B/f|B||A/f.r2|A/f.r7|A/f.mine||||||||
> >
> > See how B/f is in conflict but refers to the A/f files.
>
> I agree that the references to the A/f files should not exist. But I
> think that that's just a symptom of the issue that a copy of a conflicted
> item shouldn't be conflicted.
>
> For the text conflict, if we tweak the marker file paths at the copy
> destination, then the left and right files (B/f.r2 and B/f.r7) give the
> impression that B/f existed with these contents at the given revisions.
> But that's highly unlikely.
>
> For a copied property-conflicted item X, the .prej file at the copy
> destination contains something like
>
> Trying to add new property 'score' with value '1',
> but property already exists with value '2'.
>
> which is also misleading. Granted, it's possible that someone just
> committed an X with property "score", value "1", after the update, but
> that has nothing to do with the current conflict.
>
> For a tree conflict victim checked out from ^/Y and copied to local
> path Z, either
>
> - nothing exists in the repos at Z's path
>
> - something exists in the repos at Z's path, but it's been deleted
> locally (the copy is the second half of a replacement)
>
> (hmmm, are there any other cases?)
>
> In either case, there's no tree conflict at Z.
I totally agree with what you say here, Stephen. The tree conflict is
unrelated to the new node that results from the copy. So it's never
right to copy the tree conflict when we copy the file or directory... at
least not unless the "copy" is in fact supposed to be half of a "move",
and maybe not even then. More about "move" below.
Last night, I wrote in this thread:
> [...] the overall answer seems clear to me:
> A tree conflict applies to a path.
But to interpret my email you first had to guess what was in my head,
because I didn't spell it out. Sorry about that. On reflection, it's
not so simple anyway. This is what I'm thinking.
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. 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".
* 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.
* 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).
* 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.
Thoughts?
- Julian
> [...] 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.
Received on 2011-05-27 15:24:08 CEST