On Fri, Aug 20, 2010 at 5:46 PM, Hyrum K. Wright <hyrum_wri...@mail.utexas.edu> wrote: > On Fri, Aug 20, 2010 at 7:35 AM, C. Michael Pilato <cmpil...@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.row...@gmail.com
