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

update vs status, where should local mods be displayed?

From: Mo DeJong <supermo_at_bayarea.net>
Date: 2001-09-13 03:51:06 CEST

Hi all.

I have a quick question about local modifications and where
they should be displayed. I have noticed that `svn update`
does not display the names of files with local mods.
It will display a U when a new rev is pulled down,
but it mentions nothing about a local modification,
a local deletion, or a local addition. This is quite
different from how CVS works so I fear it may take quite
some getting used to. I do like the conceptual separation
between a `svn status` and a `svn update` but I really
get the feeling subversion would be more useful if
the output of these two commands were a bit different.

For example, I often do a `cvs update` to make sure everything
is up to date and to figure out which files to pass to a commit
subcommand.

To do this with subversion, I could run update and then status,
and sift through the (very long) output of the status subcommand
to figure out which files were locally modified/added/deleted.

% svn update
% svn status > status

% grep "M " status
M 95 ( 95) ./configure.in
M 95 ( 95) ./gen-make.py
% grep "A " status
A 0 ( 95) ./buildcheck.sh

% svn commit configure.in gen-make.py buildcheck.sh

While that is certainly doable, it is clearly not as easy as
running `cvs update`.

I did find this -M flag that can be passed to the status subcommand
(there was no mention of this flag in clients/cmdline/README).
When passed, the svn_cl__print_status_list function will only print
those entries that have been "modified".

% svn -M status
M 95 ( 95) ./autogen.sh
M 95 ( 95) ./build.conf
M 95 ( 95) ./configure.in
M 95 ( 95) ./gen-make.py

My first reaction to this is that the definition of modified used in
svn_cl__print_status_list should include those files that are
locally added or deleted. That would certainly make the output more
useful when the -M flag is passed.

(Possible output)

% svn update
% svn -M status
M 95 ( 95) ./configure.in
M 95 ( 95) ./gen-make.py
A 0 ( 95) ./buildcheck.sh

% svn commit configure.in gen-make.py buildcheck.sh

Of course, the fact that a -M flag exists in the first place just
makes me think that the default output of the status command is
simply too verbose. Perhaps the status command should only print
info about files that have actually changed when recursing.

For example, here is a quick snip from the output of status
on my machine:

_ 95 ( 95) ./ac-helpers/install.sh
_ 95 ( 95) ./ac-helpers/svn-apache.m4
_ 95 ( 95) ./ac-helpers/svn-macros.m4
M 95 ( 95) ./autogen.sh
M 95 ( 95) ./build.conf
A 0 ( 95) ./buildcheck.sh

What information does the first three lines really provide?
Can't we communicate that the install.sh, svn-apache.m4,
and svn-macros.m4 files are up to date and have not been
changed by not printing a line of output for them?

This can be quite a problem even for a small repo
with hundreds of entries. Sifting through thousands
of entries worth of output would be even worse.

What I am suggesting is that the default output of the
status command should not display every file. Instead
the default should display info for locally modified
file, locally added files, and locally deleted files
(I assume modified props would also apply here). We
could add a `svn status -v` option to print out the
really verbose output that is currently displayed.

On a related but separate note, should the `svn update`
command do something similar? It currently ignores
local mods, adds, and deletes.

I am certainly willing to work on implementing these
changes, I just want to get some feedback from the
group before starting down this path.

cheers
Mo DeJong

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