Johan Corveleyn wrote on Wed, Sep 26, 2012 at 22:19:02 +0200: > [ 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? >
Create a $Checksum$ keyword that expands to something like $Checksum: sha1=da39a3ee5e6b4b0d3255bfef95601890afd80709 $ (or md5 if that is available --- or sha512 if we start using that someday) . It should be possible to add (during checkout the client has the reported-by-server checksum), and the rep-cache feature in the FS allows easily writing a tool that extracts the fulltext from the checksum. (Actually extracting a (fspath, pegrev) pair is another matter --- I think it's not efficiently possible in BDB and possible in FSFS due to things that are borderline implementation details.) > 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
