Den tis 17 juni 2025 kl 06:24 skrev Yasuhito FUTATSUKI <
futat...@yf.bsdclub.org>:

> Hello,
>
> On 2025/06/16 18:06, 管理员 wrote:
> > If the file name ends with a space, it cannot be save to a file then use
> the --targets options:
> >
> > For example:
> >
> > Files:
> >
> > /Users/abc/trunk/aaa
> > /Users/abc/trunk/aa      // ends with a space.
> >
> > create a file:  /Users/abc/trunk/1.txt, contents:
> >
> > /Users/abc/trunk/aaa
> > /Users/abc/trunk/aa      // ends with a space.
> >
> > execute svn command:
> >
> > svn add --targets  /Users/abc/trunk/1.txt
> >
> > svn: warning: W155010: '/Users/abc/trunk/aa' not found
> > svn: E200009: Could not add all targets because some targets don't exist
> > svn: E200009: Illegal target for the requested operation
>
>
> > Subversion client version: 1.14.5
> > Subversion server version: 1.14.5
> > OS: macOS 15.5
>
> I could confirm the issue. With --targets option, the content
> of the target file is splited by new line, and each lines are
> trimed trailing white space(s).
>
> The behaviour can be changed with following patch, but I have no
> confidence that the current behaviour is intended or not.
> [[[
> Index: subversion/svn/svn.c
> ===================================================================
> --- subversion/svn/svn.c        (revision 1926152)
> +++ subversion/svn/svn.c        (working copy)
> @@ -2409,7 +2409,7 @@
>            SVN_ERR(svn_stringbuf_from_file2(&buffer, utf8_opt_arg, pool));
>            SVN_ERR(svn_utf_stringbuf_to_utf8(&buffer_utf8, buffer, pool));
>            opt_state.targets = svn_cstring_split(buffer_utf8->data, "\n\r",
> -                                                TRUE, pool);
> +                                                FALSE, pool);
>          }
>          break;
>        case opt_force:
> ]]]
>
> Note: Of course, file names endts with spaces can be add
> by passing exact the file name to svn add, e.g. with most
> shells on Unix like OS,
>
> $ svn add '/Users/abc/trunk/aa '
>
> or
>
> $ svn add /Users/abc/trunk/aa\
>                               ~ one space here.
> Cheers,
> --
> Yasuhito FUTATSUKI <futat...@yf.bsdclub.org>
>
>
Hi,

Best as I can tell this was changed in r842098
<https://svn.apache.org/r842098> where the original call to
svn_cl__newline_to_array() was replaced with svn_cstring_split() with the
TRUE argument:
[[[
@@ -950,7 +949,8 @@
              svn_pool_destroy (pool);
              return EXIT_FAILURE;
            }
-         opt_state.targets = svn_cl__newlinelist_to_array(buffer, pool);
+         opt_state.targets = svn_cstring_split (buffer->data, "\n\r",
+                                                 TRUE, pool);
]]]

If I'm reading the code right (the function svn_cl__newlinelist_to_array()
was removed in 842098 so you need to do `svn cat
subversion/clients/cmdline/util.c@842097`), LEADING whitespace was
removed/ignored but trailing whitespace was kept intact. The change above
would resolve the reported issue but also keeping leading whitespace.

For the record, r842098 was committed in 2002!

So I see a few different possible actions
1. Keep current behaviour (basically declaring this works as expected).
This has been the behaviour since at least Subversion 1.1.
2. Commit the patch above, changing behaviour for those relying on trimming
preceding (and possibly trailing) whitespace.
3. Recreating behaviour of svn_cl__newlinelist_to_array() by adding a
separate parameter to svn_cstring_split() so we can control separately the
removal of preceding and trailing whitespace. (This is public API so we
need to create a new svn_cstring_split2()).

I personally think it should be possible to specify any legal filenames in
the --targets file. Files with preceding or trailing whitespace is possible
under Linux. It seems NTFS also allow this but the Windows shell trim both
ends, cmd.exe allow creating files with preceding whitespace. I haven't
checked macOS.

I'm less inclined to restore the original behaviour (ie option 3) since it
files with preceding whitespace would still not be possible to specify in
the --targets file AND we would create regressions for people who expect
trailing whitespace to be trimmed.

Thus I'm leaning towards 2, even though it may create a regression for any
user of Subversion 1.1 or later. Let's call it +0.8.

Cheers,
Daniel

Reply via email to