Re: Incorrect LastChangedRev in working copy after committing directory move + modified file in subdir

On Tue, Jul 3, 2012 at 2:09 PM, Vincent Lefevre <vincent-svn_at_vinc17.net> wrote:
> On 2012-07-03 13:21:35 +0200, Johan Corveleyn wrote:
>> I just tested my scenario with 1.6: it doesn't have the same issue
>> (subdir has LastChangedRev 3 in both the working copy and the
>> repository). So this is a regression in 1.7.
>
> The reason why "subdir" has LastChangedRev 3 may be because its parent
> directory "dir" was renamed to "dir2": with Subversion 1.6, when a
> directory was copied, all its descendents had their LastChangedRev
> bumped to this commit revision. Do you confirm?
>
> Could you try the same test without modifying test.txt in rev 3?
> I think you'll also see LastChangedRev 3 on subdir with 1.6.

Interesting. The issue you reported is indeed similar, but it's more
subtle than appears at first. There is a difference between 1.6 and
1.7, but *only in the committing working copy*, not in the repository.
The behavior is also different if the WC is mixed-rev before the "svn
mv", as opposed to uniform revision.

1) Uniform rev

svnadmin create repos
svn mkdir -mm $REPOS/dir # creates rev 1
svn co $REPOS wc
cd wc
echo blah > dir/file.txt
svn add dir/file.txt
svn commit -mm # creates rev 2
svn up # uniform rev 2
svn mv dir dir2
svn commit -mm # creates rev 3

With 1.6:
- In originating WC: LCR of file.txt is 3
- In repository: LCR of file.txt is 2

With 1.7:
- In originating WC: LCR of file.txt is 2
- In repository: LCR of file.txt is 2

So I believe that 1.6's behavior in the working copy is indeed
incorrect, and that the LCR of a child was always intended to be
unaffected by the move/copy of a parent dir. That's the behavior of
the repository, in both 1.6 and 1.7. What you saw with 1.6 (LCR 3 on
file.txt) was only true in the originating working copy, which means
that all other working copies will get LCR 2. Not good :-). And that
has apparently been fixed in 1.7.

2) Mixed rev

svnadmin create repos
svn mkdir -mm $REPOS/dir # creates rev 1
svn co $REPOS wc
cd wc
echo blah > dir/file.txt
svn add dir/file.txt
svn commit -mm # creates rev 2
svn mv dir dir2
svn commit -mm # *** out-of-date error
svn up # tree conflict (only 1.6 [1])
svn resolve --accept=working dir # only needed with 1.6
svn commit -mm # creates rev 3

With 1.6:
- In originating WC: LCR of file.txt is 3
- In repository: LCR of file.txt is 3

With 1.7:
- In originating WC: LCR of file.txt is 3
- In repository: LCR of file.txt is 3

So it seems the situation is different with a mixed revision scenario,
but at least it's consistent between 1.6 and 1.7, and between
originating WC and repository.

Also, the notifications on commit are different between uniform rev
and mixed-rev (same for 1.6 and 1.7):

Uniform rev:
Deleting dir
Adding dir2

Mixed rev:
Deleting dir
Adding dir2
Adding dir2\test.txt

(that just indicates to me that in the mixed-rev situation, something
is done explicitly with test.txt (different working rev as parent
dir), which might explain the bumping of LCR in this case)

Conclusion: what you saw seems to be a bug in 1.6 (causing incorrect
bumping of LCR in originating WC), which got fixed in 1.7. What I now
found seems to be a similar bug introduced in 1.7 (incorrect
non-bumping of LCR in intermediate subdir in originating WC).

-- 
Johan