On Fri, 2009-09-25, Stefan Sperling wrote:
> 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.
>
> Julian,
>
> 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.
Thanks. Yes, I've just been studying this and I misunderstood it before.
It's fine.
> Here's an example session that illustrates the current behaviour
> (with a trunk build):
>
> $ svn rm alpha
> D alpha
> $ svn cp beta alpha
> A alpha
> $ svn st
> R + alpha
> $ svn up
> C alpha
> At revision 3.
> Summary of conflicts:
> Tree conflicts: 1
> $ svn st
> A + C alpha
> > local replace, incoming delete upon update
So far so good, assuming the incoming change really was a "delete" (or a
move).
> $ svn info alpha
> Path: alpha
> Name: alpha
> URL: file:///tmp/svn-sandbox/repos/trunk/alpha
> Repository Root: file:///tmp/svn-sandbox/repos
> Repository UUID: 02c3fca4-a95f-11de-a728-535ddc7658c0
> Revision: 3
> Node Kind: file
> Schedule: add
> 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)
> Checksum: f0cf2a92516045024a0c99147b28f05b
> Tree conflict: local replace, incoming delete upon update
> Source left: (file) ^/trunk/alpha_at_2
> Source right: (none) ^/trunk/alpha_at_3
That looks lovely. The details of the incoming change look correct, the
node kinds are correct, and the base revision is updated to 3. "My"
version of the node is preserved as the working version, by
re-scheduling it as a copy of beta_at_2, where previously the existing node
was scheduled to be replaced with a copy of beta_at_2.
> 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.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2400033
Received on 2009-09-25 01:39:54 CEST