On Wed, Jul 4, 2012 at 2:11 PM, Vincent Lefevre <vincent-svn_at_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_at_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
Received on 2012-07-04 14:27:00 CEST