[SVN-620] wc inconsistency bug in copies

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Duplicate
• Affects Version/s: all
• Fix Version/s: 0.30
• Component/s: libsvn_wc
• Labels: bite-sized

Environment

other

• Assignee: Unassigned
• Reporter: Ben Collins-Sussman
• Created: 04/Feb/02 01:27
• Updated: 27/Oct/18 16:43
• Resolved: 15/Sep/04 08:43

Description

Found an wc inconsistency bug in the way copies work.

cd wc1
svn cp A/B/E A/D/newdir
svn ci
svn st -v
         ---> all of A/D/newdir claims to have CR 2, including children

cd wc2
svn up
svn st -v
         ---> only A/D/newdir has CR2, but contents are at CR 1!

The second case is correct, technically; I mean, the children of
A/D/newdir technically *do* have a CR of 1 on the server.  The only
reason they claim to have CR2 in the first case is due to the
(incorrect) way we bump items after a commit: the added children were
'targets' of the commit, and so our post-commit bumping logic assumes
that they have a CR of the new revision.  But that's not true --
because they're adds-with-history, these aren't new node-ids at all.

So I think our post-commit bumping process needs to *not* bump the
entry-props on commit targets that were 'added with history'.  Need to
think about how to make this happen.

Issue Links

• duplicates: SVN-1525 Use new "entity ID" notion instead of "committed rev"