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

Re: tree conflicts with replace

From: Bill Tutt <bill.tutt_at_gmail.com>
Date: Thu, 13 Aug 2009 10:51:15 -0400

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


Received on 2009-08-13 17:04:25 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.