zsh-workers
 help / color / Atom feed
From: "Daniel Shahaf" <d.s@daniel.shahaf.name>
To: zsh-workers@zsh.org
Cc: "Cristiano De Michele" <cristiano.demichele@uniroma1.it>
Subject: _subversion is going to need to use 'help -v'
Date: Sat, 31 Aug 2019 20:19:45 +0000
Message-ID: <b96fd102-a60d-4ad6-831f-ea7fcd9f1011@www.fastmail.com> (raw)

tl;dr: A change made to Subversion (upstream) trunk today affects _subversion.

_subversion completes subcommands based on the output of `svn help`.

Subversion upstream have just made a change whereby subcommands named
x-* will not be shown in `svn help`, but only in `svn help -v`.  The change will
presumably be released in 1.13.0 in October (unless something comes up in
post-commit reviews upstream).

I assume we should, at least, teach _subversion to pass -v if the 'svn'
binary is new enough.  That would let x-* subcommands continue to be
offered. We could try either «svn help -v || svn help» or «if [[ `svn
--version -q` == (2.*|1.<13->.*) ]]; then …; else …; fi».

Upstream is also discussing hiding some options by default, but that
hasn't been implemented yet.

Any volunteers to look into this?

Cheers,

Daniel

P.S. Speaking of experimental svn features, is anyone using both
shelving and vcs_info?

julianfoad@apache.org wrote on Sat, 31 Aug 2019 06:49 +00:00:
> Author: julianfoad
> Date: Sat Aug 31 06:49:24 2019
> New Revision: 1866188
> 
> URL: http://svn.apache.org/viewvc?rev=1866188&view=rev
> Log:
> Issue #4828, Hide experimental commands and options by default.
> 
> * subversion/libsvn_subr/opt.c
>   (print_command_info3,
>    print_generic_help_body3): Show commands and options starting with
>     'x-' only if new 'with_experimental' option is true.

             reply index

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-31 20:19 Daniel Shahaf [this message]
2019-09-04  2:54 ` Daniel Shahaf
2019-10-10 16:29   ` Mikael Magnusson
2019-10-10 16:58     ` [PATCH] _subversion: Fix syntax error in 44726/0001 Daniel Shahaf

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b96fd102-a60d-4ad6-831f-ea7fcd9f1011@www.fastmail.com \
    --to=d.s@daniel.shahaf.name \
    --cc=cristiano.demichele@uniroma1.it \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

zsh-workers

Archives are clonable: git clone --mirror http://inbox.vuxu.org/zsh-workers

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.workers


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git