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 <jcor...@gmail.com> > An: Volker Daum <volker.d...@gmx.net> > CC: users@subversion.apache.org > Betreff: Re: Wrong last changed rev after "svn cp" > On Wed, Sep 26, 2012 at 4:58 PM, Volker Daum <volker.d...@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
