On Thu, Mar 26, 2009 at 09:21:07AM -0400, John Peacock wrote:
> David O'Shea wrote:
> > On 26/03/2009 13:02, Stefan Sperling wrote:
> >> On Thu, Mar 26, 2009 at 01:23:28AM +0100, Branko Cibej wrote:
> >>> However, before you design fancy progress meters, you should consider
> >>> how they interact with the current comman-line output. The output of SVN
> >>> commands is meant to be easily parseable by wrapper scripts, etc; the
> >>> progress meter must not break that feature.
> >> You could always show a progress bar by default, but provide a command
> >> line switch which scripts can use to disable the progress bar.
> > Perhaps disabled by the "--non-interactive" switch?
> I don't think that would be acceptable. In the past, the Subversion
> project has treated CLI output as falling under the compatibility
> guarantees. You could /ask/ for the progress output (think RPM's -h and
> rsync's --progress options), but I don't think it can be the default.
Evidence seems to suggest the contrary.
We've changed the default output before:
Although we try hard to keep output from the command line programs
compatible between releases, new information sometimes has to be added.
This can break scripts that rely on the exact format of the output.
Although the Subversion developers try hard to keep output from the
command line programs compatible between releases, new information
sometimes has to be added.
I don't think we should be restricting our options of improving the
CLI just because we might be breaking scripts we don't control.
There are good reasons to stay binary-compatible.
But staying compatible to sh/awk/python/perl/etc-scripts that parse
CLI output is not worth the hassle in my opinion.
I suppose such scripts are usually written for a specific environment,
where people usually have control over which version of Subversion
they are using.
If people want some degree of compatibility for scripts, they can use
Received on 2009-03-26 14:45:01 CET