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

Re: update vs status, where should local mods be displayed?

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-09-14 03:58:54 CEST

On Thu, Sep 13, 2001 at 05:12:12PM -0500, Ben Collins-Sussman wrote:
> Joe Orton <joe@manyfish.co.uk> writes:
> > I don't understand why people want to overload the "status" command with
> > doing updatey things. "status" should show me the status of the WC - end
> > of story. If you want some kind of "will an update change my WC"
> > command, add a --dry-run to "update", like make has, or something.
> You don't think a "status report" on your working copy should tell you
> what's out of date? CVS's status report certainly does, and I don't
> think that's a misfeature.

Just because CVS does, doesn't mean that we should. Joe's point about local
vs remote is good, and is kind of where I believe I was going in my post.
Just hadn't really got there :-)

> Taken from our spec:

That is rather disengenious. The spec does not say what we should be doing.
It is merely a document of thoughts from well over a year ago.

I think I'm in agreement with Joe, and would certainly appreciate an "svn
status" that is entirely local and only talks about what I've done in my WC.

If I want information about the *repository*, then I can use a different
command. If that is "svn update" or "svn repstat", then fine.

Let's go back to the use cases.

(1) what did I change?

(2) what is out of date?

In option 1, an output that says:

M foo/bar.c
A baz.h
M bleeb.c

Is exactly what I'm looking for. Adding --verbose will give the other

If I want repository-based information, then I can run something else.


Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:41 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.