> > - (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.
>
> Surely thats the sort of thing that a "--quiet" flag should be
> doing?
I'm saying I think that behavior is more functional, and should be the
default.
> > - (Less Radical.) After telling you about each file it touched, CVS
> > should print a blank line, and then reiterate the things which
> > require attention.
>
> If by that you mean that every other line of output is blank, then
> it seems to be producing masses of output, which would be a) time
> consuming, and b) exaserbating the problem.
Not at all. Ideally, `svn update' should print a paragraph like the
following for each file it changed:
Pursuant to the semantics of the command which you have so
forthrightly invoked, I have {updated/deleted/created} a file in
your working directory {path here} which is named {name}, in
accordance with the current contents of the repository {name}.
Followed by ten blank lines.
> How about option number three:
>
> - After processing all the files, (perhaps printing errors as it
> goes), the errors could all be duplicated, eg:
Yes, that's what I meant.
It used to be that compilers would spit out amazing amounts of
information as they worked --- their versions, target architectures,
the files being compiled, the sizes and addresses of the functions and
link modules generated, and so on.
The Unix folks did a *wonderful* thing when they decided that `cc'
should produce no output when the compilation went smoothly. We have
failed to extend this principle to our build processes today because
1) we can't tell what directory things are happening in without make
jibbering constantly at us while it hops from one directory to the
next, filling our compilation logs with information which is 90%
useless, and 2) we're worried our compilations will hang. These are
wimpy reasons, and we all suffer daily because of them.
Received on Sat Oct 21 14:36:12 2006