On Tue, Jul 3, 2012 at 11:31 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> 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).
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
Received on 2012-07-03 23:36:54 CEST