On Wed, Jul 4, 2012 at 1:24 PM, Vincent Lefevre <vincent-...@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
