Re: Split the functions of `cvs update'?

Steve Kemp writes:

> No, I don't think its silly.
>
> What I think is silly is having to perform an update to
> see what you've changed.
>
> It should be possible to see a list of the files you've got
> which are different than the corresponding files in the repository,
> _without_ having to merge - and potentially get conflicts from.
>

Just my $0.02:

I usually just do a 'cvs diff' to see what files have changed. If I
don't want to see the actual diff, I run:

cvs -q diff | grep RCS

This is obviously only a slightly different method than running cvs
status through grep.

I think Matt B's point is well taken that this is a something the
average user should not have to do to get very simple information.

I personally disagree with the idea of using cvs update to see that
files have changed. No offense to anyone, but the command is "cvs
update". If you don't want to update your working copy, don't use
that command. The fact that "cvs up" has a very readable format that
covers what files have changed is incidental, IMO.

However, I also agree that it would be nice if cvs (svn) status had a
more terse form. I have found that the normal output of cvs status is
very useful. Yet, from the general concensus, it is just as useful to
have output that gives much simpler information that is still in the
realm of file "status".

Rather than having a new command "svn changes", why not just have some
local options to "svn status": like a long form and a short form?

-- 
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 
lefty@red-bean.com <<!>>  and a knife in winter.