[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: Vincent Lefevre <vincent-svn_at_vinc17.net>
Date: Wed, 4 Jul 2012 14:46:04 +0200

On 2012-07-04 13:28:21 +0100, Philip Martin wrote:
> Vincent Lefevre <vincent-svn_at_vinc17.net> writes:
> > The output ends with:
> >
> > + cat dir2/file
> > $Header: file:///tmp/my-test-svn/svn/dir1/file 2 2012-07-04 11:57:43Z vlefevre $
> > + svn cat file:///tmp/my-test-svn/svn/dir2/file_at_3
> > $Header: file:///tmp/my-test-svn/svn/dir2/file 2 2012-07-04 11:57:43Z vlefevre $
> >
> > file:///tmp/my-test-svn/svn/dir1/file_at_2 exists but this isn't the
> > real URL of the file.
>
> That's a keyword expansion bug, a variation on issue 1975.
>
> > file:///tmp/my-test-svn/svn/dir2/file_at_2 doesn't exist.
> >
> > IMHO, the most intuitive Header string should have
> >
> > file:///tmp/my-test-svn/svn/dir2/file 3
>
> 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.

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

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Received on 2012-07-04 14:46:40 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.