On Thu, Aug 19, 2010 at 11:35:13PM -0700, C. Michael Pilato wrote:
> See http://subversion.tigris.org/issues/show_bug.cgi?id=3693
>
> Would it make sense for a multi-target update (such as 'svn update *') to
> print headers for each of its targets?
>
> $ svn up projects/*
> Updating 'projects/ezt'.
> At revision 30.
> Updating 'projects/phidx'.
> At revision 47.
> Skipped 'projects/spec.subversion'
> Skipped 'projects/spec.viewvc'
> Updating 'projects/subversion'.
> U projects/subversion/site/publish/roadmap.html
> U projects/subversion/site/publish/style/site.css
> U projects/subversion/trunk/build/generator/build_zlib.ezt
> U projects/subversion/trunk/contrib/server-side/fsfsverify.py
> U projects/subversion/trunk
> Updated to revision 987382.
> Updating 'projects/subversion-tigris'.
> Updated to revision 111.
> Updating 'projects/svnbook'.
> Updated to revision 3771.
> [...]
> $
>
> Or, perhaps we could instead change the final summary line to mention the
> target:
>
> $ svn up projects/*
> 'projects/ezt' already at revision 30.
> 'projects/phidx' already at revision 47.
> Skipped 'projects/spec.subversion'
> Skipped 'projects/spec.viewvc'
> U projects/subversion/site/publish/roadmap.html
> U projects/subversion/site/publish/style/site.css
> U projects/subversion/trunk/build/generator/build_zlib.ezt
> U projects/subversion/trunk/contrib/server-side/fsfsverify.py
> U projects/subversion/trunk
> Updated 'projects/subversion' to revision 987382.
> Updated 'projects/subversion-tigris' to revision 111.
> Updated 'projects/svnbook' to revision 3771.
> [...]
> $
>
> I think I prefer the latter approach. Would it be too much of a change to
> our long-established output to make our compatibility alarms stay silent?
In my mind, we shouldn't favour scriptability over usability.
So just go ahead with output improvements.
We've already changed the CLI output quite a bit in the past, and have been
carefully noting output changes in the release notes to help people spot
changes that might break their scripts.
People who expect API-like compatibility guarantees from the CLI client
should be scripting against the bindings instead.
> If so, would the former change be more palatable?
Either way to improve it seems fine. The current output is clearly lacking.
Stefan
Received on 2010-08-20 11:24:17 CEST