BTW, see http://subversion.apache.org/faq#version-value-in-source
Johan - perhaps mention the "wrapper around 'svn ci'" approach there?
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.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
Received on 2012-09-30 16:32:27 CEST