Re: Incorrect LastChangedRev in working copy after committing directory move + modified file in subdir
Vincent Lefevre <vincent-svn_at_vinc17.net> writes:
> On 2012-07-03 23:31:55 +0200, Johan Corveleyn wrote:
>> 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.
> Actually, in the past, this was not regarded as incorrect. There has
> already been a fix in 1.4 and 1.5 the other way around concerning
> this particular problem (in addition to other problems). See
> and the latest paragraph of my bug report (and the duplicates).
> The problem now is that the URL + the LastChangedRev together can
> no longer identify the file, because the LastChangedRev can now be
> incorrect as a peg revision.
If you are saying that a move should update the LastChangedRev of every
file (and dir?) in the destination then that would break the cheap copy
feature of Subversion's copy-on-write filesystem.
Cerified & Supported Apache Subversion Downloads:
Received on 2012-07-04 13:51:53 CEST
This is an archived mail posted to the Subversion Dev