Den mån 9 okt. 2023 kl 07:05 skrev Nathan Hartman <hartman.nat...@gmail.com
>:
> On Sun, Oct 8, 2023 at 3:14 PM Daniel Sahlberg
> <daniel.l.sahlb...@gmail.com> wrote:
> > I was able to reproduce the issue and thanks to Yasuhito's hints I was
> also able to fix it by using absolute paths when running the svn command.
> I've committed r1912826 with a simple fix which seems to work for me.
> >
> > Nathan, can you verify if it also works for you?
>
> Thanks Daniel and Yasuhito for your help!
>
> With r1912826, the test passes now.
>
Great, thanks for confirmation!
>
> I had trouble determining what's different about this test as compared
> to others with expected errors containing wc paths. As I described
> previously, I experimented with different ways to construct the
> expected_error, but I hadn't considered to call the svn command itself
> with absolute paths!!
>
> Just to tie up all the loose ends, replying to some earlier questions:
>
> On Fri, Oct 6, 2023 at 3:33 PM Daniel Sahlberg
> <daniel.l.sahlb...@gmail.com> wrote:
> > From the test:
> >
> > [[[
> > was_cwd = os.getcwd()
> > from_path = os.path.abspath(sbox.ospath(''))
> > to_path = os.path.abspath(sbox.ospath('F/B'))
> > os.chdir(wc_dir)
> > ]]]
> >
> > Would be interesting to know the values of was_cwd, return value of
> sbox.ospath("") and how that translates with os.path.abspath() and the same
> for "F/B".
>
> Even though this is a moot point now, before you wrote your reply I
> instrumented the test and printed these out, so for completeness:
>
> was_cwd = /home/nathan/ramdrive/svndev/svn-trunk/subversion/tests/cmdline
>
> from_path:
> sbox.ospath('') = svn-test-work/working_copies/copy_tests-17
> os.path.abspath(sbox.ospath('')) =
>
> /home/nathan/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/svn-test-work/working_copies/copy_tests-17
>
> to_path:
> sbox.ospath('F/B') = svn-test-work/working_copies/copy_tests-17/F/B
> os.path.abspath(sbox.ospath('F/B')) =
>
> /home/nathan/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/svn-test-work/working_copies/copy_tests-17/F/B
>
> Expected:
> svn: E200007: Cannot move path
>
> '/home/nathan/ramdrive/svndev/svn\-trunk/subversion/tests/cmdline/svn\-test\-work/working_copies/copy_tests\-17'
> into its own child
>
> '/home/nathan/ramdrive/svndev/svn\-trunk/subversion/tests/cmdline/svn\-test\-work/working_copies/copy_tests\-17/F/B'
>
> Actual:
> svn: E200007: Cannot move path
>
> '/home/nathan/ramdrive/svndev/ramdisk/svn-trunk/working_copies/copy_tests-17'
> into its own child
>
> '/home/nathan/ramdrive/svndev/ramdisk/svn-trunk/working_copies/copy_tests-17/F/B'
>
> >> I am assuming that in the expected path, 'svn-test-work' is probably a
> >> symlink to ~/ramdrive/svndev/ramdisk. I can't check this at the moment
> >> but I will try rerunning later and I'll inspect these locations.
>
> Yes, svn-test-work (subversion/tests/cmdline/svn-test-work) is indeed
> a symlink in my case.
>
I was able to get the test cases to fail with the exact same setup. It
seems the \- in the "expected" was a red herring, it obviously doesn't
affect the Expected/Actual check so I guess it is added in the printout
somehow.
Starting the test cases directly and adding the --development option was
very helpful in debugging:
[[[
cd subversion/tests/cmdline/
./copy_tests.py 17 --development
]]]
>
> > The symlink being an artefact from your custom build system? Sounds like
> you might be on to something.
>
> The tools/dev/unix-build/Makefile.svn (svn-check-prepare-ramdisk
> target) constructs this if you specify RAMDISK in the call to 'make',
> e.g.,:
>
> $ make svn-check RAMDISK=$SVN_DEV/ramdisk
>
Are the custom targets in Makefile.svn something that should be added to
the repository? I was blown away by the performance running the tests on a
ramdisk, would be really useful to have, but I had to manipulate each test
to replace the work folders with symlinks before running make check.
Kind regards,
Daniel
