On Wed, Aug 12, 2009 at 9:02 PM, Julian Foad <julianfoad_at_btopenworld.com>wrote:
On Thu, 2009-08-13, Neels Janosch Hofmeyr wrote:
> Hi tree-conflicts folks,
>
> the irony, we were just discussing atomic replace, when a tree-conflict
> failure with replaces in it pops up.
Hi Neels.
>
> There are several tree-conflict deficiencies and bugs such as this one
> that I'd like to take a look at some time, but I've been doing other
> things instead.
>
> [...]
> > [[[ > $ svn revert
> > Reverted 'alpha'
> > $ svn st
> > ? alpha
> > ]]]
> >
> > --> Wait, the local changes were both a "delete" and an "add". Only the
> > "add" got reverted. Is that intended? BASE seems to be in-between the
> atomic
> > replace (sorry for the language). That's bad.
>
>
I've always thought that a pending "replace" when reverted should decompose
into the underlying operations and only revert the non-delete operation.
That way the svn status command in your above example would output:
[[[
svn st
D alpha
]]]
The idea behind this behavior is the svn command line shouldn't mind read
the user's intention behind issuing the revert command.
svn doesn't know if the user wants to revert the delete as well as the add.
Note: I'm purposefully not suggesting what the directory state should be for
the above svn status output in the WC. I merely bring this up to encourage
discussion.
Bill
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383315
Received on 2009-08-13 17:04:25 CEST