Julian Foad wrote:
> 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".
>
It shouldn't IMNSHO. The whole point of "true renames" is to preserve
object identity ... if we allow copy+delete to do that, then we lose the
ability to do a copy+delete that doesn't preserve object identity.
In a slight modification, of this scenario, it could be argued that
copy+delete in a *single* commit could potentially be converted to a
move, for compatibility with older clients; but never if they come in
separate commits.
I think that the the tree-conflict logic combining this into a move, as
described in the original post, would already be massively wrong:
because the result would be different if Elaine happened to do an update
before the delete came into the repository. Regardless of the sequence
of commits from Fred and Elaine's updates, the result in Elaine's
working copy should be the same.
-- Brane
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2395446
Received on 2009-09-16 12:34:40 CEST