[ cc -= dev@subversion.a.o ] Hi APR devs,
The below report about a problem with Subversion working on 'subst'ed drives (Windows), seemed to be related to a change in APR 1.7.0 (https://svn.apache.org/r1855950), and was cross-posted between dev@subversion and dev@apr. Without any context this was probably not the best way to draw attention of the apr devs (sorry), so I'll try again :-). The problem was actually nicely summarized already last November by Stefan Küng and Evgeny Kotkov on dev@subversion (but unfortunately not escalated upstream), see https://svn.haxx.se/dev/archive-2019-11/0157.shtml: On Tue, Nov 19, 2019 at 9:44 PM Evgeny Kotkov <evgeny.kot...@visualsvn.com> wrote: > > Stefan Kueng <tortoise...@gmail.com> writes: > > > Using svn 1.13.0 on Windows: > > > > SUBST G:\ D:\Development\TestWC > > G: > > svn st . > > > > ! . > > ? Foo > > ? src\nonversioned > > > > As you can see, the root folder doesn't show the correct status. > > This showed the correct status with 1.12.x. > > On my side, this issue *does not* reproduce with Subversion 1.13.0 built > against APR 1.6.x, but reproduces with the TortoiseSVN 1.13.1 command-line > binaries. > > I see that TortoiseSVN 1.13 has recently switched to APR 1.7.0, so that may > be causing the issue: > > https://osdn.net/projects/tortoisesvn/scm/svn/commits/28674 > > Among the changes in APR 1.7.0, this one could be responsible for the faulty > behavior, since it changes how apr_stat() works for reparse points: > > https://svn.apache.org/r1855950 > > > Regards, > Evgeny Kotkov Can one of the APR developers please take a closer look? It's not clear to me whether it's a new bug in APR 1.7.0, introduced by r1855950 (causing problems for simple subst'ed drives), or whether it's an intended behavior change, and the Subversion usage is doing something wrong. To be clear: I haven't looked closely at the source code myself (I'm just trying to build SVN on Windows, and trying to determine whether I should go for APR 1.7.0 or 1.6.x). For reference, below is the latest report on dev@subversion, which was cross-posted to dev@apr. Thanks. On Thu, Jan 2, 2020 at 1:51 PM Mikael Rahbek <m...@skov.dk> wrote: > > Hi > > Thank you for replying to my question! > > Here are 2 command line printouts. > > First is from R:\ > > Microsoft Windows [Version 10.0.18363.535] > (c) 2019 Microsoft Corporation. All rights reserved. > > R:\>svn info > Path: . > Working Copy Root Path: R:\ > URL: > http://svn.skov.com/svn/ARM-ControlSW/ControlSW/branches/features/Production_work_7_1 > Relative URL: ^/ControlSW/branches/features/Production_work_7_1 > Repository Root: http://svn.skov.com/svn/ARM-ControlSW > Repository UUID: 2a7e9ce4-0f0a-8847-ab6a-1601258db52d > Revision: 84889 > Node Kind: directory > Schedule: normal > Last Changed Author: mr > Last Changed Rev: 84879 > Last Changed Date: 2020-01-02 09:07:18 +0100 (to, 02 jan 2020) > > > R:\>svn status > !M . > X Applications\BasicControl > ? Applications\FarmnetInterface\WinFarmNet\.vs > ? Applications\FarmnetInterface\WinFarmNet\Debug > ? Applications\FarmnetInterface\WinFarmNet\WinFarmNet\Debug > X Applications\GUI > X Applications\PluginInstaller\SimLauncherLib > > And from C:\Data\Production_work_7_1_Clean: > > Microsoft Windows [Version 10.0.18363.535] > (c) 2019 Microsoft Corporation. All rights reserved. > > C:\Data\Production_work_7_1_Clean>svn info > Path: . > Working Copy Root Path: C:\Data\Production_work_7_1_Clean > URL: > http://svn.skov.com/svn/ARM-ControlSW/ControlSW/branches/features/Production_work_7_1 > Relative URL: ^/ControlSW/branches/features/Production_work_7_1 > Repository Root: http://svn.skov.com/svn/ARM-ControlSW > Repository UUID: 2a7e9ce4-0f0a-8847-ab6a-1601258db52d > Revision: 84889 > Node Kind: directory > Schedule: normal > Last Changed Author: mr > Last Changed Rev: 84879 > Last Changed Date: 2020-01-02 09:07:18 +0100 (to, 02 jan 2020) > > > C:\Data\Production_work_7_1_Clean>svn status > M . > X Applications\BasicControl > ? Applications\FarmnetInterface\WinFarmNet\.vs > ? Applications\FarmnetInterface\WinFarmNet\Debug > ? Applications\FarmnetInterface\WinFarmNet\WinFarmNet\Debug > X Applications\GUI > X Applications\PluginInstaller\SimLauncherLib > > Svn info seems to be the same, but svn status indicate that in the root they > are different: > > R:\>svn status > !M . > > And > > C:\Data\Production_work_7_1_Clean>svn status > M . > > Regards > > Mikael > > -----Original Message----- > From: Julian Foad <julianf...@apache.org> > Sent: 2. januar 2020 13:13 > To: Mikael Rahbek <m...@skov.dk> > Cc: dev@apr.apache.org; d...@subversion.apache.org > Subject: Re: Subversion reports status fault on substituted drive > > Mikael Rahbek wrote: > > As part of our development we use a substituted drive (Windows 10): > > > > E.g.: > > > > subst r: C:\Data\Production_work_7_1_Clean > > > > In the root of r: there is now always shown a change with status > > missing > > > > If checking from C:\Data\Production_work_7_1_Clean it shows the status > > correct. > > Thank you for reporting this problem. > > If you can reproduce the issue using 'svn' command-line commands like 'svn > status', then please show the actual commands and their output. > > (If you cannot, then please report the problem to the TortoiseSVN project > instead.) > > Also please show the output of 'svn info' in both places, like this: > > [[[ > C: > cd \Data\Production_work_7_1_Clean > svn info > ]]] > > and > > [[[ > r: > cd \ > svn info > ]]] > > > The problem is new in 1.13.1, Build 28686 (TortoiseSvn) > > > > Before 13 this was not a problem. > > > > I have been told that the reason for the fault could be because > > subversion APR is changed from 1.6.x to 1.7.0? > > I can't do Windows debugging myself but if you provide the above information > there is a good chance that somebody here will be able to debug it. > > - Julian -- Johan
