[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Split the functions of `cvs update'?

From: Matthew Braithwaite <matt_at_braithwaite.net>
Date: 2000-10-27 10:34:45 CEST

Two observations:

  Problems caused by merging changes from the repository are (much)
  harder to debug when you are unaware that a merge has taken place.
  Therefore, merges should always be explicitly requested by the user.

  `cvs update' has a dual function: it reports the status of your
  working copy in a compact format, and it merges changes from the
  repository. If you want the former function, you may forget that
  you are getting the latter as well.

One frequently does a `cvs update' in order to answer the question,
``now, what files did I modify, again?'', because it gives the handy

        M foo.h
        M foo.h
        D a.out

display that we all know and love -- compact, somewhat
machine-readable, etc. Unfortunately, to get that display, you have
to accept the side effects of `cvs update'. AFAIK it's not available
from any other command.

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.

Accordingly I think it might make sense to re-package the handy status
function of `cvs update' in a separate command. (Unfortunately `cvs
status' is already taken.) The idea is to avoid conflating ``tell me
the status of my working copy'' with ``update my working copy with new
stuff from the repository.''

Maybe it'd be worthwhile to remove the `update' command entirely and
creating two new commands like `svn show' and `svn merge'; I don't
know.

Does this help the ``Command line verbosity'' question at all? If the
two functions of `cvs update' were split as I describe, `svn merge'
could report *only* from-repository modifications of the working copy,
and the user would have to do `svn show' if he wanted to see his local
modifications. Do people find value in having these two kinds of
status reporting intermingled?
Received on Sat Oct 21 14:36:12 2006

This is an archived mail posted to the Subversion Dev mailing list.