I like the less radical option. I do pay attention to all the
left-side letters as an update happens, usually, but I also page back
through to look for conflicts. Since conflicts are rare, summarizing
them again at the end seems like a good compromise, as they won't
normally push much other data off the screen anyway.
Completely agree that just cloning the CVS way would be not going far
enough, by the way.
-K
Jim Blandy <jimb@savonarola.red-bean.com> 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 '>>>>>>'
> somewhere.
>
> 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
> message?)
>
> 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.
Received on Sat Oct 21 14:36:12 2006