On Fri, Apr 10, 2020 at 4:19 PM Johan Corveleyn <jcor...@gmail.com> wrote:
>
> 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.
FYI, another data point:
I just saw a new report on the TortoiseSVN mailinglist, where a user
sees exactly the same problem with a "shared folder", where the
wc-root is the share-root:
https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/tortoisesvn/jgHE5_sHfFI/xOpP1Ce3AAAJ
Quoting:
[[[
C:\Users\ta>svn status \\computer-a\shared-working-copy
! \\computer-a\shared-working-copy
]]]
I'm guessing this is the same problem with "drive-roots", just as with
subst or the root of real drives.
--
Johan
