On Thu, Apr 9, 2020 at 6:31 PM William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> On Thu, Apr 9, 2020 at 8:01 AM Johan Corveleyn <jcor...@gmail.com> wrote:
>>
>> On Thu, Apr 9, 2020 at 1:20 PM Nick Kew <n...@apache.org> wrote:
>> > >
>> > > 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),
>> >
>> > That fixed a bug PR#47630 that had been extensively discussed in
>> > bugzilla and shows as having 22 watchers - that's a lot of interest!
>> >
>> > Does that discussion not throw any light on your issue? For example,
>> > Michael Schlenker's comments there refer to that bug affecting SVN.
>>
>> Thanks, I've read through that issue in Bugzilla now.
>>
>> It definitely seems like a useful improvement for proper support of
>> (different types of) reparse points on Windows. I'm not saying this
>> bugfix needs to be reverted. And indeed, Michael Schlenker's comments
>> point to a specific problem affecting SVN (in combination with Windows
>> Data Deduplication, which creates reparse points with tag
>> IO_REPARSE_TAG_DEDUP). So in general this is a step forward, and will
>> probably benefit SVN for use on these specific types of Windows
>> systems.
>>
>> However, I think this also broke something (or at least inadvertently
>> changed something) related to the usage of "SUBST" (as in 'SUBST G:\
>> D:\Development\TestWC'). The usage of "subst" is not mentioned
>> anywhere in PR#47630, so perhaps the compatibility with / impact on
>> subst was overlooked? I'm not an expert at all, but from what I could
>> find with a quick internet search, "subst" is very old (from MSDOS
>> times), and it seems it's not the same as a junction (? not sure about
>> the relation between subst and reparse points in general). In any
>> case, it's not clear to me that the fix for PR#47630 intended to
>> change something for "subst".
>
>
> That's very likely, and this can be researched further to dig up exactly how
> subst is handled. (As you mention, it hasn't been common since the
> introduction
> of proper junction and directory/file symlinks.)
>
> It appears that the root directory is always problematic for an svn checkout
> (actually, most checkouts were problematic on svn when junctions or symlinks
> were in play on windows.) Looks like some additional special handling is going
> to be required even with queries on c:\ (a real, not a substituted volume
> root.)
Thank you for looking into this.
You're absolutely right: with TSVN 1.13 (APR 1.7.0) I get the same
erroneous behavior when 'svn -st'-ing a checkout to C:\ (real drive)
[[[
C:\>svn st -q
! .
]]]
Doing the same with SlikSVN 1.12 (APR 1.6.5), there is no problem:
[[[
C:\>"Program Files\SlikSvn\bin\svn.exe" st -q
]]]
(no output, as it should be -- I've made no modifications)
> Can you successfully `svn co {repos} /` on linux? Hoping to understand the
> scope of the issue.
Sorry, no Linux at my disposal where I'm root. But I suppose the test
above with the checkout to C:\ already confirms your hypothesis.
--
Johan
