On 2023/10/09 18:05, Daniel Sahlberg wrote:
Den mån 9 okt. 2023 kl 10:30 skrev Yasuhito FUTATSUKI <
futat...@yf.bsdclub.org>:
On 2023/10/09 4:14, Daniel Sahlberg wrote:
Den lör 7 okt. 2023 kl 06:52 skrev Yasuhito FUTATSUKI <
futat...@yf.bsdclub.org>:

If svn is called with relative paths, it can only see
cwd as a realpath, and absolute paths of argment paths
are composed from it.  So the paths in error message we
can expect here is absolute real paths or relative paths
only (It assumes that relative paths passed from the
command line don't contain symlinks).

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.

I don't think r1912826 is a correct fix. For the main purpose of
the test, checking SVN-4913 is surely fixed, it is correct,
but then how the error message should be when the arguments are
passed in the form of relative paths ?


Just so I understand your question, are you asking what the ACTUAL error
message should be when passed a relative path (which may contain a symlink)?

Yes. As far as I read "Error message conventions"[1] and description
for canonical form[2], I cannot see explicitly what it should be.

[1] Error message conventions, Coding andCommit Conventions
https://subversion.apache.org/docs/community-guide/conventions.html#error-messages

[2] Detailed Description, svn_dirent_uri.h File Reference
https://subversion.apache.org/docs/api/latest/svn__dirent__uri_8h.html#details

If this is the question, then it goes deep within the library where the
relative path is resolved to an absolute path. The error message has always
returned the absolute path (libsvn_client/copy.c, approx 3100). Maybe it
> would have been better to return a path relative to the wc root?

Generally it depends on the system design, not the implementation how
do we treat the paths passed in argments, in for each error messages.
But I think that using the absolute path is correct in this case,
at least within libsvn_client/copy.c: try_copy().

Anyways, I don't think it is right that changing how it checked if
the test pattern is not wrong for the purpose.  And even if the
test pattern is wrong for the purpose, I think this pit fall should
be tested here, or elsewhere (even if it is a bug in test case itself).

Cheers,
--
Yasuhito FUTATSUKI <futat...@yf.bsdclub.org>

Reply via email to