Re: Potential regression: high server-side memory consumption during import
Philip Martin wrote: Julian Foad writes: Can someone file an issue in the tracker please. I need to refer to it in discussion with potential rc1 trials. https://issues.apache.org/jira/browse/SVN-4723 Thanks for that and SVN-4722. - Julian
Re: svn commit: r1826328 - in /subversion/trunk/subversion: include/svn_opt.h libsvn_subr/opt.c
julianf...@apache.org wrote on Fri, 09 Mar 2018 11:06 +:
> * subversion/include/svn_opt.h,
> subversion/libsvn_subr/opt.c
> (SVN_OPT_MAX_PARAGRAPHS,
>svn_opt_subcommand_desc3_t,
>svn_opt_get_canonical_subcommand3,
>svn_opt_get_option_from_code3,
>svn_opt_subcommand_takes_option4,
>svn_opt_print_generic_help3,
>svn_opt_subcommand_help4,
>svn_opt_print_help5): New.
>
> +++ subversion/trunk/subversion/include/svn_opt.h Fri Mar 9 11:06:23
> 2018
> @@ -69,6 +69,9 @@ typedef svn_error_t *(svn_opt_subcommand
> /** The maximum number of options that can be accepted by a subcommand.
> */
> #define SVN_OPT_MAX_OPTIONS 50
>
> +/** The maximum number of paragraphs of help text a subcommand can have. */
Missing "@since New in 1.11" annotation.
> +#define SVN_OPT_MAX_PARAGRAPHS 50
> @@ -77,6 +80,37 @@ typedef svn_error_t *(svn_opt_subcommand
> /** One element of a subcommand dispatch table.
> *
> + * @since New in 1.11.
> + */
> +typedef struct svn_opt_subcommand_desc3_t
> +{
...
> +} svn_opt_subcommand_desc3_t;
> +
> +
> +/** One element of a subcommand dispatch table.
> + *
> * @since New in 1.4.
> */
Mark as deprecated? (Also other symbols in this commit)
> typedef struct svn_opt_subcommand_desc2_t
Cheers,
Daniel
Re: [PATCH] Split long strings into paragraphs to ease translation
Completed (initially) in r1826352. Help strings are split into paragraphs (at their existing blank lines in fact) across most but not all 'svn*' command-line tools. Tracked as issue SVN-4724 "Split long help strings into paragraphs to ease translation" https://issues.apache.org/jira/browse/SVN-4724 Now let's see what follow-up we need. Can you try it and see if it seems to be working, Mattias? - Julian Mattias Engdegård wrote: Julian Foad wrote: One issue occurs to me. If we make this change, splitting all the long strings into paragraphs, won't that cause one enormous headache to the translators because they will then have a bunch of paragraph-length strings that the translation tools think are untranslated individually, even though translations of them existed as substrings of a previous long string? Probably, but it's a one-time cost. The old translations will still be in the file as obsolete strings, for reference. And chances are that those strings are currently fuzzy anyway, if the translations haven't been updated for some time. How could we ease that transition? It looks like it could be quite easy to write a script that updates the .po files, if we choose our new breaks to be at a deterministic points (e.g. every empty line), and if the current translations keep the same structure (1:1 paragraphs) as the English version. Would that work with most translators' work flows? Maybe, but it sounds brittle and error-prone, and we may not necessarily want to break at every empty line (the "merge" help, for example, contains lots of ASCII art that may or may not belong with a paragraph of prose). Since we don't know what parts are up to date, we would have to be pessimists and mark them all as fuzzy.
