On Tue, Jul 3, 2012 at 11:31 PM, Johan Corveleyn <jcor...@gmail.com> wrote: > 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).
Forgot the footnote: [1] http://subversion.tigris.org/issues/show_bug.cgi?id=3526 (Commit of newly added file followed by move (or delete) of parent dir causes tree conflict) -- Johan
