On Wed, Jul 4, 2012 at 2:11 PM, Vincent Lefevre <vincent-...@vinc17.net> wrote: > On 2012-07-04 13:58:50 +0200, Johan Corveleyn wrote: >> > 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? > > Well, this is more complex that I thought, and 1.7 really has an > inconsistency. My example is in my reply to Philip Martin.
Ah yes, you're right. We now have two clearly separate discussions: - Inconsistencies in LCR between originating WC and repository. That's my main interest right now. I think those are clearly bugs (1.6 had one, and now 1.7 has another one it seems). - Whether or not LCR should be updated if a parent directory gets moved/renamed. That's more a discussion of specification, what's the desired behavior, ... That's a bit out of my personal scope right now, but maybe others will participate further in this discussion. You mentioned one concrete use-case which breaks down because of this: being able to identify a file with URL@LCR (I'm not sure if this is (or ever was) an intended use-case). Is there other behavior that depends on this? Now that I think about it: the current behavior of "LCR not bumped by parent move/copy" is there at least since 1.5. We have a 1.5 repository, and I'm pretty used to the fact that, when I look at a branch or tag with a repository browser, that I see the LastChangedRev and LastChangeAuthor and Date as being the last "real modification" of that file (not the revision which copied the file to the branch/tag). I kinda like that behavior... -- Johan
