> -----Original Message-----
> From: Stephen Butler [mailto:sbut...@elego.de]
> Sent: vrijdag 27 mei 2011 12:26
> To: Philip Martin
> Cc: Julian Foad; Subversion Development
> Subject: Re: issue 3899 (copying conflict victims)
>
>
> On May 26, 2011, at 17:56 , Philip Martin wrote:
>
> > Julian Foad <julian.f...@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.
> >
> > Suppose file "A/f" is in conflict:
> >
> > $ sqlite3 wc/.svn/wc.db "select * from actual_node"
> > 1|A/f|A||A/f.r2|A/f.r7|A/f.mine||||||||
> >
> > 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.
Isn't that the same behavior as we had in 1.0-1.6: a copy is just a copy of
the actual node in the working copy with metadata changed to track its
history, without copying the conflict?
Any reason why we can't simply define: copy doesn't copy conflicts?
(My guess is that we just copy conflicts now, because it was easier to just
copy the db row)
Bert
