Future-proofing "svn st" output

Imagine that Subversion gains some new feature, such as
reserved checkouts, that associates extra state with each
item in the working copy. Then it might be good for "svn st"
or "svn st -v" to start showing that extra state.

Unfortunately, that isn't possible because the output of
those commands is supposed to be easy for other programs
to understand, and at present the only way for those
other programs to identify the fields in "svn st" output
is to split each line of output into fixed-size chunks --
and that would stop working if the format were changed
at all.

So, "svn st" would need to grow another option to show
the extra state. And then if another new feature which
attaches even more state to each item comes along,
another new option would be needed. And so on. Ouch.

I see several possibilities.

0. Never add any fields to "svn st" output; if a feature
   would require them, don't add it.

   That seems too restrictive.

1. Accept the above scenario; hope that new features
   requiring such changes are rare.

   This seems sad too, because (a) it means a proliferation
   of options to "svn sn" and (b) it means that the output
   with any particular option can never change. (So, in
   particular, "svn st" and "svn st -v" couldn't change their
   output format.)

2. Break third-party programs that parse "svn st" output
   when a new feature comes along that wants extra fields
   in that output.

   I don't like this one either. If parseability of the output
   is a Subversion feature, then it should be stable too.

3. Change the output of "svn st" once and for all, so as
   to make it extensible. For instance, output a header line
   first which defines the fields somehow, and then specify
   that the way third-party programs should parse the output
   is by deducing which columns they need from the header line.

   This seems sensible to me, though the header line may be
   unpopular with others. Another approach that wouldn't
   require a header line: stop using whitespace to mean
   absence-of-flag for things like "out of date" and "added
   with history", and then say that the first N whitespace-separated
   columns will always mean what they do now, and the last
   will always be the filename. (But what about filenames
   with whitespace in?)

4. Offer some separate way for third-party programs to discover
   which columns they need. For instance, an option that makes
   "svn st" output a list of field names and columns.

   This is another option-proliferating approach, though the
   proliferation is fairly mild. It has the dubious advantage
   that the show-me-the-column-definitions option could give
   the information in a form that's friendly to humans as well
   as to computers.

The same goes, mutatis mutandis, for other Subversion commands.
"svn st" seems clearly the most important, though.

I can't quite shake off the feeling that I may be worrying
about a non-problem; but I also can't see why it's a non-problem.
Am I missing some obvious reason why none of this matters?

I remark that the widths of the columns for "svn st -v" are
different in all three of (1) the output of "svn help status",
(2) the examples in the Handbook, and (3) the actual output.

-- 
g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org