On Fri, Aug 20, 2010 at 5:46 PM, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> On Fri, Aug 20, 2010 at 7:35 AM, C. Michael Pilato <cmpilato_at_collab.net> 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?
>> If so, would the former change be more palatable?
>
> As a distracting aside: this may be a opportunity to think about other
> commands which do (or could) interface with multiple working copies.
> Also, would something similar be appropriate when doing multiple
> commits with one command line client invocation?
The only problem with only listing it afterwards is that (particularly
on Windows) there's a noticeable delay before the update of each
external/working copy. From a usability standpoint, it's probably
better to keep that initial header.
Not to say that the final message couldn't be more verbose.
--
Geoff Rowell
geoff.rowell_at_gmail.com
Received on 2010-08-22 13:25:09 CEST