[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Wed, 04 Jul 2012 14:01:36 +0100

Vincent Lefevre <vincent-svn_at_vinc17.net> writes:

> On 2012-07-04 13:28:21 +0100, Philip Martin wrote:
>> Where would the revision 3 come from? LastChangedRev is 2. That's what
>> Subversion's cheap copy means.
> Yes, but I meant that LastChangedRev could be 3 after a move.
> I don't think this contradicts cheap copy: when doing
> svn cat file:///tmp/my-test-svn/svn/dir2/file_at_3
> Subversion gets the file via a COPY node or something like that
> (I don't know the exact internals) as the file hasn't changed,
> and it could get LastChangedRev from it.

No, it doesn't follow a copy. dir2_at_3 has a reference to the the same
child object as dir1_at_2. dir2/file_at_3 is exactly the same object as
dir1/file_at_2. That's what a cheap copy means.

If you make a commit that explicitly modifies dir2/file then the
node-rev-id of dir2/file will get a new copy-id but until that happens
it's the same node as dir1/file.

> My point is that <URL>@<LastChangedRev> should always be a valid
> reference to the file, and it should be equivalent to <URL>@HEAD
> or just <URL>.

That's not the way it works. I think you want:

   -r<LastChangedRev> <URL>@<Revision>

i.e. take the current URL_at_Revision and go back to LastChangedRev.

Cerified & Supported Apache Subversion Downloads:
Received on 2012-07-04 15:02:13 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.