Jim Blandy writes:
> We're having so much fun talking about command line options, I thought
> I'd bring up another spiffy question.
> When I do an update, CVS spits out a line for every file it changes.
> If there are a lot of changes (which happens often), and there is a
> conflict anywhere but in the last screenful of output, and I don't
> *watch* the CVS command running, I end up trying to compile '>>>>>>'
> Anytime I have to carefully grub through pages of output, most of
> which is just "business as usual", I think the interface is borken.
> (The output from the usual Unix build process is another great
> example. Why can't it just be silent if all goes well, and otherwise
> print out a full pathname, the command it was executing, and the error
I rather like getting spammed by my system as it builds or runs
something. I find it comforting to actually *see* that my system is
doing what I told it to do. I often get nervous when I run a command,
nothing seems to happen and then my prompt returns. I mean, I *know*
something happened and I may very well exactly what that was, but I
*feel* better actually seeing it happen.
That being said, I totally agree with what Jim is saying at the same
time. I too have been bitten when I do an update and missed the
conflicts because they scrolled way the hell up in my shell buffer.
> Here are two possible solutions that occurred to me:
> - (Radical.) CVS shouldn't print out the lines of the files it
> modifies unless you ask it to. Honestly, do you really read all of
> them and examine the changes? It should only report things that
> need attention, like conflicts.
> - (Less Radical.) After telling you about each file it touched, CVS
> should print a blank line, and then reiterate the things which
> require attention.
These are both excellent suggestions and I think they can be looked at
as two aspects of the same solution:
(I will assume that when Jim said "CVS should/shouldn't", he was
also suggesting "SVN should/shouldn't" :) )
- SVN will always report things that need attention, like conflicts.
These things will always be the last thing returned by the client to
guarantee the user sees it. The user has the option of turning on
or off all other messages (things that don't require attention) that
will always appear above attention-needing things in the outpout
Now, whether the default is that "all other messages" are on or off is
also subject to further discussion, I think.
Lee P. W. Burgess <<!>> Manipulate eternity. Power is a symphony:
Programmer <<!>> elaborate, enormous, essential.
Red Bean Software <<!>> Dream the moment with a fiddle in summer
firstname.lastname@example.org <<!>> and a knife in winter.
Received on Sat Oct 21 14:36:12 2006