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