On Tue, Jul 3, 2012 at 2:09 PM, Vincent Lefevre <vincent-...@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
