[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: Julian Foad <julian.foad_at_wandisco.com>
Date: Thu, 26 May 2011 16:40:20 +0100

On Thu, 2011-05-26 at 17:18 +0200, Stephen Butler wrote:
> On May 26, 2011, at 16:32 , Julian Foad wrote:
>
> > On Thu, 2011-05-26 at 13:42 +0200, Stephen Butler wrote:
> >> I've assigned issue 3899 "forbid wc-wc copy/move of conflict victims"
> >> to myself, but I think it needs a little more discussion.
> >>
> >> The basic idea is that the conflict data (including marker files) includes
> >> references to "their" version from the repository, which would be invalid
> >> anywhere else in the working copy.
> >
> > Why would a repos location be invalid? What do you mean exactly?
>
> That the repos location mentioned in the conflict data doesn't match the
> repos location of the copy/move target.
>
> Suppose I check out ^/trunk to /tmp/wc, and later there's a conflict at
> /tmp/wc/A. If I
>
> cd /tmp/wc
> svn mv A B
>
> then B has conflict data derived from ^/trunk/A, which doesn't make
> sense anymore.

The conflict data will say that the incoming change was the change from
^/trunk/A_at_LEFT and ^/trunk/A_at_RIGHT. That does make sense. There is
still a ^/trunk/A_at_LEFT and a ^/trunk/A_at_RIGHT in the repo. They are the
repos locations that were being diffed and merged or updated into the
directory that is now locally located at /tmp/wc/B. I see no problem
with this info.

I am not saying there are no problems with such copies/moves, just I
don't see a problem with the conflict-source info.

- Julian

>
> We could remove the conflict data (from the copy/move target)
> automatically, I suppose, perhaps with an implicit '--accept mine-full'.
> This would require supporting --accept for tree conflicts, which we
> haven't designed yet.
>
> Steve
>
> >
> >
> >> In an issue comment, Philip says:
> >>
> >> Perhaps we should simply prohibit copies where a conflict exists?
> >> That would also solve another problem: actual-only node conflicts
> >> are not copied.
> >>
> >> Along those lines, I propose to forbid copy or moving:
> >>
> >> 1. any conflict victim (text, property, or tree)
> >>
> >> 2. any directory containing conflicted children
> >>
> >> 3. any child of a tree-conflicted directory
> >>
> >> These apply to the move/copy source only. Resolving a tree conflict
> >> may require copying or moving an item /into/ a conflicted tree.
> >>
> >> Also, a property conflict on a directory should not prevent copying or
> >> moving the directory's children.
> >>
> >> Comments?
> >>
> >> I have a simple solution for #1 above, and the beginning of a test.
> >> I'll commit them if I get a +1.
> >>
> >> Regards,
> >> 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
>
>
Received on 2011-05-26 17:40:58 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.