On Wed, Sep 23, 2009 at 07:23:52PM +0100, Stefan Sperling wrote:
> > (do_entry_deletion): If we raise a tree conflict because the node is locally
> > replaced, re-schedule the node for addition (without history) rather than
> > trying to delete it.
> > ### Without history sounds wrong. A replacement can be with or without history,
> > ### and the schedule-add should correspondingly be with or without history.
> Agreed. Should be possible to fix.
your concern here is already addressed.
The log message isn't entirely accurate.
What the log message should have said is that we don't override any
existing copyfrom information. We *do* override existing copyfrom
information in the "local add vs. incoming delete" case.
But when re-adding locally replaced items, we keep any existing copyfrom
info. E.g. if you replace a file alpha like this:
svn rm alpha
svn cp beta alpha
and then do an update which tries to delete alpha, alpha will be
scheduled for re-add and retain its copyfrom pointer to beta,
rather than getting a copyfrom pointer to alpha_at_pre-update-rev.
Here's an example session that illustrates the current behaviour
(with a trunk build):
$ svn rm alpha
$ svn cp beta alpha
$ svn st
R + alpha
$ svn up
At revision 3.
Summary of conflicts:
Tree conflicts: 1
$ svn st
A + C alpha
> local replace, incoming delete upon update
$ svn info alpha
Repository Root: file:///tmp/svn-sandbox/repos
Repository UUID: 02c3fca4-a95f-11de-a728-535ddc7658c0
Node Kind: file
Copied From URL: file:///tmp/svn-sandbox/repos/trunk/beta
Copied From Rev: 2
Last Changed Author: stsp
Last Changed Rev: 1
Last Changed Date: 2009-09-25 00:07:21 +0100 (Fri, 25 Sep 2009)
Tree conflict: local replace, incoming delete upon update
Source left: (file) ^/trunk/alpha_at_2
Source right: (none) ^/trunk/alpha_at_3
So what we should be asking ourselves is if this behaviour is entirely
correct. I'm not gonna try to answer this question at 00:15 hours.
I'll think more about it tomorrow.
Any additional comments appreciated!
Received on 2009-09-25 01:20:46 CEST