Neels Janosch Hofmeyr wrote:
> Hi tree-conflicts folks,
>
> I'd like to poke you guys with this scenario:
Yes, that's what we need. It's where "true renames" support intersects
with tree conflicts.
> [[[
> # fred's WC: copy, edit and remove something in three separate commits.
> $ svn copy foo bar ; svn ci
> $ $EDITOR bar ; svn ci
> $ svn delete foo ; svn ci
The three commits are a distraction from your main point. Let's just say
"svn move foo bar; $EDITOR bar; svn ci" for the purposes of this
example, to make it clear that Subversion is supposed to recognize this
as a "move". In designing "true renames" support we can discuss whether
we want Subversion to guess that a sequence of changes like yours above
is meant to be a "move".
> # elaine's WC has a local mod on 'foo', and needs to get the new changes.
> # she's about to face a tree-conflict.
> $ svn st
> M foo
>
> $ svn up
> C foo
> > local edit, incoming move to ^/bar
> A + bar (moved from ^/foo)
> M bar
> Summary of conflicts:
> Tree conflicts: 1
> # in a sidenote, the above copy+del results in a move
>
> $ svn st
> D C foo
> > local edit, incoming move to ^/bar
>
> $ svn resolve foo
> Resolving tree-conflict on 'foo': local edit, incoming move to ^/bar
> (mt) apply mine to move-target (^/bar), (tf) discard mine/"theirs-full",
> (a) see all options? mt
> M bar
> D foo
> Resolved conflicted state of ^/foo
>
> $ svn st
> M bar
> $ svn ci -m "frobnicate."
> ]]]
Yes. I want some of this. :-)
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2395432
Received on 2009-09-16 11:55:00 CEST