You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Manuel Pégourié-Gonnard <mp...@elzevir.fr> on 2010/07/08 10:22:30 UTC
Possible bug with computation of last revision and svn cp
Hi,
The computation of the last modification revision (as in the expansion of the
$Rev$ keyword or the second column of the output of "svn status -v") seems to
depend on the update path of the working copy used, rather than only on the
history of the file in the repo. It looks wrong to me, and after asking on the
user list [1] I didn't get any convincing explanation of this behaviour, so I'd
like to have your opinion: is this a bug or do I just fail to understand why it
is to be expected?
http://mail-archives.apache.org/mod_mbox/subversion-users/201006.mbox/%3C4C124388.20201@elzevir.fr%3E
The problem happens when you do a svn copy of a directory. Afterwards, the "last
revision" of files in this directory (no modified after the cp) is computed
differently in the working copy where the cp operation was made than in any
other working copy. Running svn up in the incriminated wc doesn't change
anything, but svn up'ing to an earlier revision, then back to the last revision
does. Here is a reproducer.
svnadmin create repo
svn co file://$PWD/repo active
svn co file://$PWD/repo passive
cd active
svn mkdir dir
touch dir/file
svn add dir/file
svn ci -minitial
svn cp dir newdir
svn ci -m'after cp'
cd ..
cp -a active active-back-then-up
(cd passive && svn up)
(cd active && svn up)
(cd active-back-then-up && svn up -r1 && svn up)
svn status -v */newdir/file
The output of the final svn status -v looks as follows:
2 1 mpg active-back-then-up/newdir/file
2 2 mpg active/newdir/file
2 1 mpg passive/newdir/file
As you can see, only the "active" repo thinks newdir/file's last modification is
at revision 2, other repositories compute it as 1.
Thanks in advance for your comments,
Manuel.
Re: Possible bug with computation of last revision and svn cp
Posted by Manuel Pégourié-Gonnard <mp...@elzevir.fr>.
Le 09/07/2010 03:59, Konstantin Kolinko a écrit :
> 2010/7/8 Manuel Pégourié-Gonnard <mp...@elzevir.fr>:
>> The output of the final svn status -v looks as follows:
>>
>> 2 1 mpg active-back-then-up/newdir/file
>> 2 2 mpg active/newdir/file
>> 2 1 mpg passive/newdir/file
>>
>> As you can see, only the "active" repo thinks newdir/file's last modification is
>> at revision 2, other repositories compute it as 1.
>>
>
> It looks like
> http://subversion.tigris.org/issues/show_bug.cgi?id=620
>
Precisely. Sorry for not finding it myself.
Manuel.
Re: Possible bug with computation of last revision and svn cp
Posted by Manuel Pégourié-Gonnard <mp...@elzevir.fr>.
Le 09/07/2010 03:59, Konstantin Kolinko a écrit :
> 2010/7/8 Manuel Pégourié-Gonnard <mp...@elzevir.fr>:
>> The output of the final svn status -v looks as follows:
>>
>> 2 1 mpg active-back-then-up/newdir/file
>> 2 2 mpg active/newdir/file
>> 2 1 mpg passive/newdir/file
>>
>> As you can see, only the "active" repo thinks newdir/file's last modification is
>> at revision 2, other repositories compute it as 1.
>>
>
> It looks like
> http://subversion.tigris.org/issues/show_bug.cgi?id=620
>
Precisely. Sorry for not finding it myself.
Manuel.
Re: Possible bug with computation of last revision and svn cp
Posted by Konstantin Kolinko <kn...@gmail.com>.
2010/7/8 Manuel Pégourié-Gonnard <mp...@elzevir.fr>:
> The output of the final svn status -v looks as follows:
>
> 2 1 mpg active-back-then-up/newdir/file
> 2 2 mpg active/newdir/file
> 2 1 mpg passive/newdir/file
>
> As you can see, only the "active" repo thinks newdir/file's last modification is
> at revision 2, other repositories compute it as 1.
>
It looks like
http://subversion.tigris.org/issues/show_bug.cgi?id=620
Best regards,
Konstantin Kolinko
Re: Possible bug with computation of last revision and svn cp
Posted by Philip Martin <ph...@wandisco.com>.
Manuel Pégourié-Gonnard <mp...@elzevir.fr> writes:
> svnadmin create repo
> svn co file://$PWD/repo active
> svn co file://$PWD/repo passive
> cd active
> svn mkdir dir
> touch dir/file
> svn add dir/file
> svn ci -minitial
> svn cp dir newdir
> svn ci -m'after cp'
> cd ..
> cp -a active active-back-then-up
> (cd passive && svn up)
> (cd active && svn up)
> (cd active-back-then-up && svn up -r1 && svn up)
> svn status -v */newdir/file
>
> The output of the final svn status -v looks as follows:
>
> 2 1 mpg active-back-then-up/newdir/file
> 2 2 mpg active/newdir/file
> 2 1 mpg passive/newdir/file
>
> As you can see, only the "active" repo thinks newdir/file's last
> modification is at revision 2, other repositories compute it as 1.
>
> Thanks in advance for your comments,
Yes, that look like a bug. In 1.7 STMT_APPLY_CHANGES_TO_BASE
explicitly sets both revnum and changed_rev to the newly committed
revision.
There is a similar problem with changed_author and changed_date.
--
Philip