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?
Volker
-------- 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."
>
>
> --
> Johan
Received on 2012-09-26 18:34:58 CEST