You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Volker Daum <Vo...@gmx.net> on 2012/09/26 16:58:53 UTC
Wrong last changed rev after "svn cp"
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.
Cheers,
Volker
Re: Wrong last changed rev after "svn cp"
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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 <Vo...@gmx.net> wrote:
> > -------- Original-Nachricht --------
> >> Datum: Wed, 26 Sep 2012 17:31:02 +0200
> >> Von: Johan Corveleyn <jc...@gmail.com>
> >> An: Volker Daum <Vo...@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 <Vo...@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
Re: Wrong last changed rev after "svn cp"
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Johan Corveleyn wrote on Mon, Oct 08, 2012 at 00:02:57 +0200:
> On Sun, Sep 30, 2012 at 4:31 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > BTW, see http://subversion.apache.org/faq#version-value-in-source
> >
> > Johan - perhaps mention the "wrapper around 'svn ci'" approach there?
>
> Okay, done. I've added some text on the alternative suggestion at the
> end of that FAQ.
Thanks.
Re: Wrong last changed rev after "svn cp"
Posted by Johan Corveleyn <jc...@gmail.com>.
On Sun, Sep 30, 2012 at 4:31 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> BTW, see http://subversion.apache.org/faq#version-value-in-source
>
> Johan - perhaps mention the "wrapper around 'svn ci'" approach there?
Okay, done. I've added some text on the alternative suggestion at the
end of that FAQ.
--
Johan
Re: Wrong last changed rev after "svn cp"
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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 <Vo...@gmx.net> wrote:
> > -------- Original-Nachricht --------
> >> Datum: Wed, 26 Sep 2012 17:31:02 +0200
> >> Von: Johan Corveleyn <jc...@gmail.com>
> >> An: Volker Daum <Vo...@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 <Vo...@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
Re: Wrong last changed rev after "svn cp"
Posted by Johan Corveleyn <jc...@gmail.com>.
[ 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 <Vo...@gmx.net> wrote:
> -------- Original-Nachricht --------
>> Datum: Wed, 26 Sep 2012 17:31:02 +0200
>> Von: Johan Corveleyn <jc...@gmail.com>
>> An: Volker Daum <Vo...@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 <Vo...@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
Re: Wrong last changed rev after "svn cp"
Posted by Volker Daum <Vo...@gmx.net>.
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 <jc...@gmail.com>
> An: Volker Daum <Vo...@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 <Vo...@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
Re: Wrong last changed rev after "svn cp"
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Sep 26, 2012 at 4:58 PM, Volker Daum <Vo...@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