On Fri, Apr 10, 2020 at 3:45 PM William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Thu, Apr 9, 2020 at 2:48 PM Johan Corveleyn <jcor...@gmail.com> wrote:
>> On Thu, Apr 9, 2020 at 6:31 PM William A Rowe Jr <wr...@rowe-clan.net> wrote:
>> >
>> > 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
>> ! .
>> ]]]
>
>
> Here's another experiment that drives me batty...
>
> svn co https://svn.apache.org/repos/asf/httpd/httpd/trunk httpd-2.x
> svn co https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4 httpd-2.4
> svn co https://svn.apache.org/repos/asf/httpd/docs/trunk httpd-docs
> ln -s httpd-docs httpd-2.4/docs/manual/build
> ln -s httpd-docs httpd-2.x/docs/manual/build
> (flip the args using mklink /d or mklink /j on windows)
That's a bit special: you're creating embedded working copies, which
is already special to begin with (even if they were all normal,
separate checkouts instead of symlinks).
There is code that tries to crawl up the tree to find the working copy
root. Perhaps that is going wrong in this case, depending on your CWD.
Not sure.
> You'll see svn is fluxored until you change directory. A similar ugliness
> occurs if you attempt to check out a number of versions of httpd-test,
> and attempt to point all of the X apache-test checkouts into a single
> group.
>
> What I've determined is that apr_stat and apr_getfileinfo differ in only
> one aspect, that protections on a root directory are 700 or 777 based
> on the way we dress up fprot bits from windows ACLs, or not.
>
>> > 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.
>
>
> I'm not sure what svn is doing with the '.' root entity, but it likely made
> some absurd assumptions about symlinks.
Yes, that's very well possible. It's a difficult area I think (also:
there is the distinction between a symlink to a working copy root,
which just needs to be "read through" for svn commands to act upon,
and symlinks that are part your versioned data, which need to be
versioned and re-created as symlinks in other working copies (cf. the
"svn:special" property) -- something which currently is not supported
on Windows (junctions), they are just converted into a text file with
the link reference in it ... a long standing feature request for svn).
I'm afraid I don't have much expertise in that area of the svn code.
If we need wider input on this from the svn devs, I suppose
dev@subversion should be added back to the cc list.
However: with the issue reported here there is no symlink involved
(well, maybe sort of, with the subst case, but then it also fails on a
plain C:\ drive root). There seems to be a change in behavior between
APR 1.6.5 and 1.7.0 that makes svn see different information when the
working copy root is the root of a drive. Of course, this may very
well be svn's fault for jumping through strange hoops to work on drive
roots, and one of those hoops may have just changed form :-). I'm not
discounting that possibility at all.
--
Johan
