[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Issue #3693 -- any ideas?

From: Geoff Rowell <geoff.rowell_at_gmail.com>
Date: Sun, 22 Aug 2010 07:24:31 -0400

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.