[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: issue 3899 (copying conflict victims)

From: Bert Huijben <bert_at_qqmail.nl>
Date: Fri, 27 May 2011 12:37:39 +0200

> -----Original Message-----
> From: Stephen Butler [mailto:sbutler_at_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.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.
> >
> > 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
Received on 2011-05-27 12:38:16 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.