Re: subversion and programmable completion

[Clint Adams <clint@xxxxxxx>]

> What's not machine parseable about the current output?

The zsh completion function basically does the following:

To find out what subcommands are available, run 'svn help',
and grab everything between 'Available subcommands:' and
'Subversion is a tool for revision control.'  Subcommands
listed in parentheses are aliases to the word before the
parentheses.

For subcommands, run 'svn help <subcommand>', grab the
'usage:' line, check for the presence of 'URL' or 'PATH' on
that line, and try to complete URLs or files and directories, 
respectively, as well as the options listed after 'Valid options:'
(where options in brackets are aliases to the options outside).

There is a similar process for svnadmin.

There are several problems with this scheme:

It doesn't handle multiple usage possibilities.  For example,
usage: switch URL [PATH]   or
       switch --relocate FROM TO [PATH ... ]

usage: 1. diff [-r N[:M]] [--old OLD-TGT] [--new NEW-TGT] [PATH ...]
       2. diff -r N:M URL
       3. diff [-r N[:M]] URL1[@N] URL2[@M]

This could be solved with some more intelligent parsing.

It doesn't handle know whether or not PATH refers to files in the
repository (as in svn diff), files not yet in the repository (as in
svn add), or something else.  This could be solved with some
hardcoding in the completion function.

It doesn't know what 'arg' refers to in '-r arg', '--username arg',
'--password arg', and so on.  This could be solved with some hardcoding
in the completion function.

If the subversion help output ever is altered so that the heuristics
fail, completion will break.


None of this is a problem (other than lack of man-hours), but if svn were
to actively participate in its own command completion, I think it would be
more efficient and less error-prone.