Re: Wrong last changed rev after "svn cp"

On Wed, Sep 26, 2012 at 4:58 PM, Volker Daum <Volker.Daum_at_gmx.net> wrote:
> Hi.
>
> I have the an issue, which I already found referenced in a mailing list posting (for example here: http://mail-archives.apache.org/mod_mbox/subversion-users/201003.mbox/%3Calpine.561.2.00.1003301058490.1236@daniel2.local%3E). However I couldn't find any related issues in the bug-tracker, or other indications whether this is an intended behaviour or a bug that will be fixed.
> In short the behavior can be reproduced like this:
>
> I start from a new repository and a fresh checkout wc of the repository root:
> ---
>> mkdir A; touch A/file
>> svn add -q A
>> svn ci -q -m "add A" A
>> svn cp ^/A ^/A2 -m "add A2"
>
> Committed revision 2.
>> svn up -q
>> svn info A A/file | grep "Last Changed Rev"
> Last Changed Rev: 1
> Last Changed Rev: 1
>> svn info A2 A2/file | grep "Last Changed Rev"
> Last Changed Rev: 2
> Last Changed Rev: 1
> ---
>
> Why do the directory "A2" and the file "A2/file" have different Last Changed Revision?
>
> For my use case this is very bad, as we are using keyword substitution for $URL$ and $Rev$ in "A2/file" to uniquely identify printouts of that file, with its electronic copy in the repository. With the above behaviour that's not possible, as "A2/file" does not exist at revision 1.
>
> I reproduced the bug with version 1.7.6 (linux server and command line client; test installation), and also with an 1.6.12 server (linux production server) combined with a 1.6.17 and 1.7.6 tortoiseSVN windows client.
>

Hi Volker,

The short answer is: this is intended behavior, and you shouldn't use
the LastChangedRev as a peg revision identifier in combination with
the URL. This is not a supported use case.

See this recent dev-thread for some more discussion:

    http://thread.gmane.org/gmane.comp.version-control.subversion.devel/136663

The thread actually started with another issue related to
LastChangedRev (which was identified as a real issue, which was filed
here:
http://subversion.tigris.org/issues/show_bug.cgi?id=4203). But during
the (rather long) discussion the issue you mention actually came up.
See this mail in the thread:

    http://thread.gmane.org/gmane.comp.version-control.subversion.devel/136663/focus=136719

where C. Michael Pilato says: "Finally, (LCR, URL) was never intended
to be used a unique coordinate pair for identifying resources. That
it work out as such most of the time might be a benefit, but was not a
feature designed into the system."

-- 
Johan