[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: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Fri, 20 Aug 2010 22:46:12 +0100

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?

-Hyrum
Received on 2010-08-20 23:46:49 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.