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

Re: svn status proposal

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-09-24 22:11:13 CEST

On Mon, Sep 24, 2001 at 02:56:33PM -0500, Ben Collins-Sussman wrote:
> RADICS Peter <mitch@lbcons.net> writes:
> > hm.. don't we get notified of files present in the repo, but not in our
> > working copy? (Added) I think that would be necessary if we want to use
> > svn st -u to find out what would happen with an update.
> Aha! Yet another dimension to argue about!
> Really, this debate centers on whether you think 'svn status' should
> truly show you *everything* that would happen with an update, or
> whether -what you have- is out of date.
> Karl was saying earlier: the use case is finding out which of your
> -existing- files is going to be patched; people want to know where to
> expect merges or conflicts. Thus, you only want to know about things
> you have -- not (A)dded items on the server.

I believe his stated use case is incorrect. We want to know what an update
will do. That includes new files, and it includes what will happen to my WC.

How else do you propose to find out what an update will do?

Limiting the "what will an update do?" to *only* those files in the WC is an
artificial and low-utility limitation. If you want that limit applied, then
just use:

$ svn status --update | grep -v '^A'

In this case, we have all the information, so we can limit it. If the
--update only returns a subset, then we'll never get access to all the
information unless you add Yet Another Command.


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:42 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.