You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Franz Sirl <Fr...@lauterbach.com> on 2018/07/20 13:37:11 UTC

Some files stay at an too new revision when updating the working copy to an old revision

Hi,

this already happened a few times here, but now I managed to re-create 
it reliably.
This happens at least on Linux with subversion-1.8/subversion-1.10 and 
on Windows
with TortoiseSVN-1.9, didn't test older versions yet. Server is 
subversion-1.9.5
on Linux, a "svnadmin verify" of a repository hotcopy showed no problems

This slightly obfuscated transcript shows the problem:

-->
$ rm -rf myrepo.wc
$ svn co https://svnserver/svn/myrepo/trunk/some/path/src myrepo.wc/
...
Checked out revision 98863.
$ svn status --verbose myrepo.wc/mysrc[34].c
              98867    93474 user1        myrepo.wc/mysrc3.c
              98867    87357 user2        myrepo.wc/mysrc4.c
$ svn up -r 85950 myrepo.wc
...
At revision 85950.
$ svn status --verbose myrepo.wc/mysrc[34].c
              85950    93474 user1        myrepo.wc/mysrc3.c
              85950    83501 user3        myrepo.wc/mysrc4.c
--<

As you can see, mysrc3.c has a too high last_commit revision and also 
the content
of the file is too new after the first downgrading with "svn up -r 85950 
myrepo.wc".

The following procedure fixes the problem:

-->
$ svn update -r85950 myrepo.wc/mysrc3.c
Updating 'myrepo.wc/mysrc3.c':
At revision 85950.
$ svn status --verbose myrepo.wc/mysrc[34].c
              85950    93474 user1        myrepo.wc/mysrc3.c
              85950    83501 user3        myrepo.wc/mysrc4.c
$ svn update -rPREV myrepo.wc/mysrc3.c
Updating 'myrepo.wc/mysrc3.c':
U    myrepo.wc/mysrc3.c
Updated to revision 93473.
$ svn status --verbose myrepo.wc/mysrc[34].c
              93473    87225 user2        myrepo.wc/mysrc3.c
              85950    83501 user3        myrepo.wc/mysrc4.c
$ svn update -r85950 myrepo.wc/mysrc3.c
Updating 'myrepo.wc/mysrc3.c':
U    myrepo.wc/mysrc3.c
Updated to revision 85950.
$ svn status --verbose myrepo.wc/mysrc[34].c
              85950    83501 user3        myrepo.wc/mysrc3.c
              85950    83501 user3        myrepo.wc/mysrc4.c
--<

Is this a known problem? Could it be server-related? IOW, should I try 
to upgrade
the server to 1.10?

This is a simple oneliner to find affected files:

$ svn status --verbose --ignore-externals myrepo.wc/ | gawk '{ 
FIELDWIDTHS = "1 1 1 1 1 1 1 1 1 1 8 1 8 1 5000"; if ($13 > $11) print 
$11 " " $13 " " $15 }'

Let me know if there is anything I should try or if you need more details.

Franz



Re: Some files stay at an too new revision when updating the working copy to an old revision

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Franz Sirl wrote on Tue, 24 Jul 2018 22:00 +0200:
> It turns out this is probably issue #4700 which for some reason was 
> never approved for the 1.9 branch, even though it was already nominated 
> last October. So the version that matters here is the server version. 
> After I upgraded the server from 1.9.5 to 1.10.2 the problem is gone 
> (regardless of the client version) and all is well now.

Thanks for following up with this information!

Re: Some files stay at an too new revision when updating the working copy to an old revision

Posted by Franz Sirl <fr...@lauterbach.com>.
Am 2018-07-21 um 16:27 schrieb Franz Sirl:
> Am 2018-07-20 um 16:46 schrieb Franz Sirl:
>> Am 2018-07-20 um 15:55 schrieb Branko Čibej:
>>> On 20.07.2018 15:37, Franz Sirl wrote:
>>>> Hi,
>>>>
>>>> this already happened a few times here, but now I managed to re-create
>>>> it reliably.
>>>> This happens at least on Linux with subversion-1.8/subversion-1.10 and
>>>> on Windows
>>>> with TortoiseSVN-1.9, didn't test older versions yet. Server is
>>>> subversion-1.9.5
>>>> on Linux, a "svnadmin verify" of a repository hotcopy showed no 
>>>> problems
>>>>
>>>> This slightly obfuscated transcript shows the problem:
>>>>
>>>> -->
>>>> $ rm -rf myrepo.wc
>>>> $ svn co https://svnserver/svn/myrepo/trunk/some/path/src myrepo.wc/
>>>> ...
>>>> Checked out revision 98863.
>>>> $ svn status --verbose myrepo.wc/mysrc[34].c
>>>>               98867    93474 user1        myrepo.wc/mysrc3.c
>>>>               98867    87357 user2        myrepo.wc/mysrc4.c
>>>> $ svn up -r 85950 myrepo.wc
>>>> ...
>>>> At revision 85950.
>>>> $ svn status --verbose myrepo.wc/mysrc[34].c
>>>>               85950    93474 user1        myrepo.wc/mysrc3.c
>>>>               85950    83501 user3        myrepo.wc/mysrc4.c
>>>> --<
>>>>
>>>> As you can see, mysrc3.c has a too high last_commit revision and also
>>>> the content
>>>> of the file is too new after the first downgrading with "svn up -r
>>>> 85950 myrepo.wc".
>>>
>>> This does look strange.
>>>
>>> Is myrepo.wc/mysrc3.c a file external by any chance? Try:
>>>
>>> $ svn propget svn:externals --show-inherited-props myrepo.wc
>>
>> This command returns empty. There doesn't seem to be anything special 
>> about this file, except that it is one of the oldest in the 
>> repository. It was imported from CVS with history in 2005 
>> (subversion-1.2), but so was mysrc4.c. Also there have been not any 
>> properties set to the parent directory ever AFAICS.
>>
>>>
>>> If it isn't could you show us an (obfuscated) log of that file?
>>>
>>> $ svn log --verbose -r93474:85950 myrepo.wc/mysrc3.c
>>
>> ------------------------------------------------------------------------
>> r93474 | user1 | 2018-02-07 16:21:20 +0100 (Wed, 07 Feb 2018) | 9 lines
>> Changed paths:
>>     M /trunk/some/path/src/mysrc-defines.h
>>     M /trunk/some/path/src/mysrc1.c
>>     M /trunk/some/path/src/mysrc3.c
>>     M /trunk/some/path/src/mysrc5.c
>>     M /trunk/some/path/src/mysrc6.c
>>
>> ChangeLog...
>> ------------------------------------------------------------------------
>> r87225 | user2 | 2017-08-03 11:28:11 +0200 (Thu, 03 Aug 2017) | 1 line
>> Changed paths:
>>     M /trunk/some/path/src/mysrc-defines.h
>>     M /trunk/some/path/src/mysrc1.c
>>     M /trunk/some/path/src/mysrc3.c
>>     M /trunk/some/path/src/mysrc5.c
>>     M /trunk/some/path/src/mysrc6.c
>>
>> ChangeLog...
>> ------------------------------------------------------------------------
>> r87201 | user1 | 2017-08-02 16:58:50 +0200 (Wed, 02 Aug 2017) | 14 lines
>> Changed paths:
>>     M /trunk/some/path/src/mysrc-defines.h
>>     M /trunk/some/path/src/mysrc1.c
>>     M /trunk/some/path/src/mysrc3.c
>>     M /trunk/some/path/src/mysrc5.c
>>     M /trunk/some/path/src/mysrc6.c
>>
>> ChangeLog...
>> ------------------------------------------------------------------------
> 
> Actually I think I was able to narrow down the reason for the wrong 
> last_commit revision. Some further investigation showed that the actual 
> content of the working copy is correct, so only the last_commit revision 
> of mysrc3.c in the database is wrong.
> Looking at the details of the changes r87201, r87225 and r93474 of 
> mysrc3.c shows that they are actually adding some lines, change them and 
> then delete them again. That means the diff between r83501 and r93474 is 
> actually empty. And it seems that in this case subversion misses to 
> update the last_commit revision of mysrc3.c in the database.

It turns out this is probably issue #4700 which for some reason was 
never approved for the 1.9 branch, even though it was already nominated 
last October. So the version that matters here is the server version. 
After I upgraded the server from 1.9.5 to 1.10.2 the problem is gone 
(regardless of the client version) and all is well now.

Thanks,
Franz


Re: Some files stay at an too new revision when updating the working copy to an old revision

Posted by Franz Sirl <fr...@lauterbach.com>.
Am 2018-07-20 um 16:46 schrieb Franz Sirl:
> Am 2018-07-20 um 15:55 schrieb Branko Čibej:
>> On 20.07.2018 15:37, Franz Sirl wrote:
>>> Hi,
>>>
>>> this already happened a few times here, but now I managed to re-create
>>> it reliably.
>>> This happens at least on Linux with subversion-1.8/subversion-1.10 and
>>> on Windows
>>> with TortoiseSVN-1.9, didn't test older versions yet. Server is
>>> subversion-1.9.5
>>> on Linux, a "svnadmin verify" of a repository hotcopy showed no problems
>>>
>>> This slightly obfuscated transcript shows the problem:
>>>
>>> -->
>>> $ rm -rf myrepo.wc
>>> $ svn co https://svnserver/svn/myrepo/trunk/some/path/src myrepo.wc/
>>> ...
>>> Checked out revision 98863.
>>> $ svn status --verbose myrepo.wc/mysrc[34].c
>>>               98867    93474 user1        myrepo.wc/mysrc3.c
>>>               98867    87357 user2        myrepo.wc/mysrc4.c
>>> $ svn up -r 85950 myrepo.wc
>>> ...
>>> At revision 85950.
>>> $ svn status --verbose myrepo.wc/mysrc[34].c
>>>               85950    93474 user1        myrepo.wc/mysrc3.c
>>>               85950    83501 user3        myrepo.wc/mysrc4.c
>>> --<
>>>
>>> As you can see, mysrc3.c has a too high last_commit revision and also
>>> the content
>>> of the file is too new after the first downgrading with "svn up -r
>>> 85950 myrepo.wc".
>>
>> This does look strange.
>>
>> Is myrepo.wc/mysrc3.c a file external by any chance? Try:
>>
>> $ svn propget svn:externals --show-inherited-props myrepo.wc
> 
> This command returns empty. There doesn't seem to be anything special 
> about this file, except that it is one of the oldest in the repository. 
> It was imported from CVS with history in 2005 (subversion-1.2), but so 
> was mysrc4.c. Also there have been not any properties set to the parent 
> directory ever AFAICS.
> 
>>
>> If it isn't could you show us an (obfuscated) log of that file?
>>
>> $ svn log --verbose -r93474:85950 myrepo.wc/mysrc3.c
> 
> ------------------------------------------------------------------------
> r93474 | user1 | 2018-02-07 16:21:20 +0100 (Wed, 07 Feb 2018) | 9 lines
> Changed paths:
>     M /trunk/some/path/src/mysrc-defines.h
>     M /trunk/some/path/src/mysrc1.c
>     M /trunk/some/path/src/mysrc3.c
>     M /trunk/some/path/src/mysrc5.c
>     M /trunk/some/path/src/mysrc6.c
> 
> ChangeLog...
> ------------------------------------------------------------------------
> r87225 | user2 | 2017-08-03 11:28:11 +0200 (Thu, 03 Aug 2017) | 1 line
> Changed paths:
>     M /trunk/some/path/src/mysrc-defines.h
>     M /trunk/some/path/src/mysrc1.c
>     M /trunk/some/path/src/mysrc3.c
>     M /trunk/some/path/src/mysrc5.c
>     M /trunk/some/path/src/mysrc6.c
> 
> ChangeLog...
> ------------------------------------------------------------------------
> r87201 | user1 | 2017-08-02 16:58:50 +0200 (Wed, 02 Aug 2017) | 14 lines
> Changed paths:
>     M /trunk/some/path/src/mysrc-defines.h
>     M /trunk/some/path/src/mysrc1.c
>     M /trunk/some/path/src/mysrc3.c
>     M /trunk/some/path/src/mysrc5.c
>     M /trunk/some/path/src/mysrc6.c
> 
> ChangeLog...
> ------------------------------------------------------------------------

Actually I think I was able to narrow down the reason for the wrong 
last_commit revision. Some further investigation showed that the actual 
content of the working copy is correct, so only the last_commit revision 
of mysrc3.c in the database is wrong.
Looking at the details of the changes r87201, r87225 and r93474 of 
mysrc3.c shows that they are actually adding some lines, change them and 
then delete them again. That means the diff between r83501 and r93474 is 
actually empty. And it seems that in this case subversion misses to 
update the last_commit revision of mysrc3.c in the database.

Franz


Re: Some files stay at an too new revision when updating the working copy to an old revision

Posted by Franz Sirl <Fr...@lauterbach.com>.
Am 2018-07-20 um 15:55 schrieb Branko Čibej:
> On 20.07.2018 15:37, Franz Sirl wrote:
>> Hi,
>>
>> this already happened a few times here, but now I managed to re-create
>> it reliably.
>> This happens at least on Linux with subversion-1.8/subversion-1.10 and
>> on Windows
>> with TortoiseSVN-1.9, didn't test older versions yet. Server is
>> subversion-1.9.5
>> on Linux, a "svnadmin verify" of a repository hotcopy showed no problems
>>
>> This slightly obfuscated transcript shows the problem:
>>
>> -->
>> $ rm -rf myrepo.wc
>> $ svn co https://svnserver/svn/myrepo/trunk/some/path/src myrepo.wc/
>> ...
>> Checked out revision 98863.
>> $ svn status --verbose myrepo.wc/mysrc[34].c
>>               98867    93474 user1        myrepo.wc/mysrc3.c
>>               98867    87357 user2        myrepo.wc/mysrc4.c
>> $ svn up -r 85950 myrepo.wc
>> ...
>> At revision 85950.
>> $ svn status --verbose myrepo.wc/mysrc[34].c
>>               85950    93474 user1        myrepo.wc/mysrc3.c
>>               85950    83501 user3        myrepo.wc/mysrc4.c
>> --<
>>
>> As you can see, mysrc3.c has a too high last_commit revision and also
>> the content
>> of the file is too new after the first downgrading with "svn up -r
>> 85950 myrepo.wc".
> 
> This does look strange.
> 
> Is myrepo.wc/mysrc3.c a file external by any chance? Try:
> 
> $ svn propget svn:externals --show-inherited-props myrepo.wc

This command returns empty. There doesn't seem to be anything special 
about this file, except that it is one of the oldest in the repository. 
It was imported from CVS with history in 2005 (subversion-1.2), but so 
was mysrc4.c. Also there have been not any properties set to the parent 
directory ever AFAICS.

> 
> If it isn't could you show us an (obfuscated) log of that file?
> 
> $ svn log --verbose -r93474:85950 myrepo.wc/mysrc3.c

------------------------------------------------------------------------
r93474 | user1 | 2018-02-07 16:21:20 +0100 (Wed, 07 Feb 2018) | 9 lines
Changed paths:
    M /trunk/some/path/src/mysrc-defines.h
    M /trunk/some/path/src/mysrc1.c
    M /trunk/some/path/src/mysrc3.c
    M /trunk/some/path/src/mysrc5.c
    M /trunk/some/path/src/mysrc6.c

ChangeLog...
------------------------------------------------------------------------
r87225 | user2 | 2017-08-03 11:28:11 +0200 (Thu, 03 Aug 2017) | 1 line
Changed paths:
    M /trunk/some/path/src/mysrc-defines.h
    M /trunk/some/path/src/mysrc1.c
    M /trunk/some/path/src/mysrc3.c
    M /trunk/some/path/src/mysrc5.c
    M /trunk/some/path/src/mysrc6.c

ChangeLog...
------------------------------------------------------------------------
r87201 | user1 | 2017-08-02 16:58:50 +0200 (Wed, 02 Aug 2017) | 14 lines
Changed paths:
    M /trunk/some/path/src/mysrc-defines.h
    M /trunk/some/path/src/mysrc1.c
    M /trunk/some/path/src/mysrc3.c
    M /trunk/some/path/src/mysrc5.c
    M /trunk/some/path/src/mysrc6.c

ChangeLog...
------------------------------------------------------------------------

Looks innocent to me... Deleted some "M" lines pointing to files in 
other directories, but that's it.

Franz.

Re: Some files stay at an too new revision when updating the working copy to an old revision

Posted by Branko Čibej <br...@apache.org>.
On 20.07.2018 15:37, Franz Sirl wrote:
> Hi,
>
> this already happened a few times here, but now I managed to re-create
> it reliably.
> This happens at least on Linux with subversion-1.8/subversion-1.10 and
> on Windows
> with TortoiseSVN-1.9, didn't test older versions yet. Server is
> subversion-1.9.5
> on Linux, a "svnadmin verify" of a repository hotcopy showed no problems
>
> This slightly obfuscated transcript shows the problem:
>
> -->
> $ rm -rf myrepo.wc
> $ svn co https://svnserver/svn/myrepo/trunk/some/path/src myrepo.wc/
> ...
> Checked out revision 98863.
> $ svn status --verbose myrepo.wc/mysrc[34].c
>              98867    93474 user1        myrepo.wc/mysrc3.c
>              98867    87357 user2        myrepo.wc/mysrc4.c
> $ svn up -r 85950 myrepo.wc
> ...
> At revision 85950.
> $ svn status --verbose myrepo.wc/mysrc[34].c
>              85950    93474 user1        myrepo.wc/mysrc3.c
>              85950    83501 user3        myrepo.wc/mysrc4.c
> --<
>
> As you can see, mysrc3.c has a too high last_commit revision and also
> the content
> of the file is too new after the first downgrading with "svn up -r
> 85950 myrepo.wc".

This does look strange.

Is myrepo.wc/mysrc3.c a file external by any chance? Try:

$ svn propget svn:externals --show-inherited-props myrepo.wc

If it isn't could you show us an (obfuscated) log of that file?

$ svn log --verbose -r93474:85950 myrepo.wc/mysrc3.c

(the actual log messages are not important, only the list of changes to
the file)

-- Brane


>
> The following procedure fixes the problem:
>
> -->
> $ svn update -r85950 myrepo.wc/mysrc3.c
> Updating 'myrepo.wc/mysrc3.c':
> At revision 85950.
> $ svn status --verbose myrepo.wc/mysrc[34].c
>              85950    93474 user1        myrepo.wc/mysrc3.c
>              85950    83501 user3        myrepo.wc/mysrc4.c
> $ svn update -rPREV myrepo.wc/mysrc3.c
> Updating 'myrepo.wc/mysrc3.c':
> U    myrepo.wc/mysrc3.c
> Updated to revision 93473.
> $ svn status --verbose myrepo.wc/mysrc[34].c
>              93473    87225 user2        myrepo.wc/mysrc3.c
>              85950    83501 user3        myrepo.wc/mysrc4.c
> $ svn update -r85950 myrepo.wc/mysrc3.c
> Updating 'myrepo.wc/mysrc3.c':
> U    myrepo.wc/mysrc3.c
> Updated to revision 85950.
> $ svn status --verbose myrepo.wc/mysrc[34].c
>              85950    83501 user3        myrepo.wc/mysrc3.c
>              85950    83501 user3        myrepo.wc/mysrc4.c
> --<
>
> Is this a known problem? Could it be server-related? IOW, should I try
> to upgrade
> the server to 1.10?
>
> This is a simple oneliner to find affected files:
>
> $ svn status --verbose --ignore-externals myrepo.wc/ | gawk '{
> FIELDWIDTHS = "1 1 1 1 1 1 1 1 1 1 8 1 8 1 5000"; if ($13 > $11) print
> $11 " " $13 " " $15 }'
>
> Let me know if there is anything I should try or if you need more
> details.
>
> Franz
>
>