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

On Wed, Jul 4, 2012 at 1:24 PM, Vincent Lefevre <vincent-svn_at_vinc17.net> wrote:
> 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
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=1743
>
> and the latest paragraph of my bug report (and the duplicates).

I don't understand. It's pretty clear that 1.6 is incorrect, because
it puts a different LCR value in the originating working copy than in
the repository. That can never be good, because other working copies
will get a different value. I haven't checked older versions, but they
may have the same problem. Just the inconsistency between originating
WC and repository is clearly wrong.

Now, whether or not the 1.6 originating WC is wrong, or the 1.6
repository is wrong, that's another matter of discussion. But in any
case 1.6 contains a bug here. In 1.7 the originating WC and repository
are at least the same (for your use case at least -- not for the other
edge case I brought up).

> 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.

I'm afraid I don't follow you here either. Can you give a concrete example?

My reasoning is as follows: it's ok that the LCR isn't affected by
moves of parent directories, because that's reflected in the URL
already. So if you take URL+LCR, that will still always correctly
identify the file, won't it?

-- 
Johan