Re: Split the functions of `cvs update'?

> Matt wrote:
> Of course we all know that, after merging changes from the repository,
> you *should* check and make sure that things are still cool. But if
> you did the `cvs update' in preparation for a commit, this might slip
> your mind, with the unfortunate result that you forget that a merge
> has happened. If the merge introduces a bug, you are left wondering
> what the hell happened, until (unless) you happen to remember that you
> merged in some changes.

Interesting point. I for one have cvs aliased to 'cvs -q', and
whenever I run update and get *anything* besides all 'M's, I run
update *again* immediately to see exactly what I modified. I never for
once thought 'oh, this is a user interface issue.' Knowing cvs so well
and for so long undoubtedly makes it hard to look past certain
behaviors.

So, if I understand you correctly, then you would have two subcommands
(not necessarily named as such):

svn get-updates-from-server
svn show-local-mods

Is that more or less your intention?

(and of course, this doesn't preclude having just plain ole 'cvs
update' which would do The Right Thing)

-Fitz
Received on Sat Oct 21 14:36:12 2006