[ 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.d...@gmx.net> wrote: > -------- 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." >> > 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
