You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2010/08/20 06:35:13 UTC
Issue #3693 -- any ideas?
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?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Issue #3693 -- any ideas?
Posted by Geoff Rowell <ge...@gmail.com>.
On Fri, Aug 20, 2010 at 5:46 PM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> On Fri, Aug 20, 2010 at 7:35 AM, C. Michael Pilato <cm...@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@gmail.com
Re: Issue #3693 -- any ideas?
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Fri, Aug 20, 2010 at 7:35 AM, C. Michael Pilato <cm...@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
Re: Issue #3693 -- any ideas?
Posted by Stefan Sperling <st...@elego.de>.
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