Re: Wrong last changed rev after "svn cp"

[ Please do not top-post on this list, try to put your reply inline or
at the bottom. More below.

On Wed, Sep 26, 2012 at 6:34 PM, Volker Daum <Volker.Daum_at_gmx.net> wrote:
> -------- Original-Nachricht --------
>> Datum: Wed, 26 Sep 2012 17:31:02 +0200
>> Von: Johan Corveleyn <jcorvel_at_gmail.com>
>> An: Volker Daum <Volker.Daum_at_gmx.net>
>> CC: users_at_subversion.apache.org
>> Betreff: 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."
>>
> Hi Johan.
>
> Thanks for your reply. I was already afraid of that...
> Do you have any suggestion how I could solve my use case anyway (embedding a PEG revision in the file)?
>
> Text substitution in a pre-commit hook?
> The client knows the PEG revision of its working copy files I guess. So one could hack a keyword substitution for that into the client. How difficult would that be?
>

Hm, I don't know a good solution for that. But what you certainly
shouldn't do is manipulate the file in the pre-commit hook. That's a
recipe for problems, because after the commit the repository and the
working copy from which you committed will have a different idea about
what was committed. This makes the originating working copy corrupt.

I'm not sure if hacking your own keyword substitution is doable. There
is an open issue about custom keywords [1], but from the mere amount
of discussion and patches therein (and the age of the issue, 10 years
old) it doesn't seem like an easy problem. If you want to contribute
though, help is always welcome (in this case, I believe you'd have to
start with a design discussion on the dev-list).

Maybe someone else on this list has a good idea?

The only thing I can think of is pre-processing your files before
commit (make a wrapper around "svn commit" which does some automatic
change in the file before commit (but be careful not to mess things
up)) or some kind of post-processing after you export/checkout, before
printing the file (maybe as part of some build script or something
similar).

[1] http://subversion.tigris.org/issues/show_bug.cgi?id=890
(Implementation of Custom keywords)

-- 
Johan