On 6/17/14 6:43 PM, C. Michael Pilato wrote: > On 06/17/2014 10:40 AM, Ivan Zhakov wrote: >> [[[ >> $ svn ci wc -m "log msg" >> Sending wc\foo >> Transmitting file data . >> Finalizing commit ... >> Committed revision 5. >> ]]] > > I like this. And, it's the only one that doesn't change a line of > output that surely *countless* scripts have already been written to parse.
As I discussed with Ivan I think the output should display the percentage of files/deltas transferred, bytes transferred and bit rate over those files when the output is going to a terminal/console. Doing so means changing our existing output and outputting '\r' in order to remove the existing data and update it. We've avoided doing this in the past for reasons I'm not sure of. I'm guessing since nobody bothered to figure out how to tell if we're outputting to a terminal/console (see svn_cmdline__be_interactive()). But we're now using that to default --non-interactive which is much more intrusive in my opinion. For that matter the pager support that stsp posted a while back uses this technique as well. As such I think it's perfectly reasonable to start having fancier outputs for users that our seeing us run on a terminal. Compatibility in this case is not particularly compelling because if you're parsing this output then you probably aren't using a tty. If you're using something like expect and we break your script I really don't feel very sorry for you since we provided much better ways to drive the client than that. I hope that we can agree that not breaking scripts shouldn't stop us from improving interactive usage, especially since we can avoid breaking most scripts. The format you've agreed to doesn't really solve the problem. The user has to realize that the the dots ceasing to print without the 'Finalizing commit' line means the commit has stalled. However, in the case of large files/deltas there can be a significant delay between the dots. So the user is still provided with insufficient information to know that Subversion is still working. If we're going to change this, we should show the user as much information as we can.
