While looking at vc-svn.el I found some behaviours of 'svn status'
that I'd like to ask about. I'm using 0.16 from source.
People might call 'svn stat' on a file that doesn't exist yet. For
example, vc-svn (as currently designed) does this when you open a new
file in a directory that is controlled by Subversion. At the moment,
svn stat prints gives a blank status, as if the file was up to date,
which is misleading. It seems to me that it would be better for it to
either print '?', or at least give an error. Perhaps scripts would
generally '?' more useful, since they can easily find out for
themselves that it doesn't exist in the wc.
% ls -la
drwxr-sr-x 3 mbp mbp 4096 Dec 6 18:02 .
drwxr-sr-x 3 mbp mbp 4096 Dec 6 16:49 ..
drwxr-sr-x 8 mbp mbp 4096 Dec 6 18:02 .svn
-rw-r--r-- 1 mbp mbp 29 Dec 6 18:02 added
-rw-r--r-- 1 mbp mbp 29 Dec 6 18:02 committed
-rw-r--r-- 1 mbp mbp 29 Dec 6 18:02 extra
% svn stat extra nonexistent
'svn stat -u' on a file that has been added but not committed gives an
% svn stat added
% svn stat -u added
svn: Filesystem has no item
svn: file not found: transaction `d', path `/trunk'
I can see how from a certain point of view this is accurate, since the
file doesn't exist on the server. However, I can't see how this is
useful to a human or script trying to use 'svn stat -u'. In
particular, it doesn't tell you about the case where a file has been
added and committed in another revision.
It is somewhat confusing that 'svn stat -u' doesn't give a "superset"
of the information from 'svn stat', but rather different information.
As far as I can see, this means that something like vc-svn needs to
run both 'svn stat' and 'svn stat -u' to properly handle the case of
files being added and also to discover out-of-date files.
This is different to the behaviour of just stating the directory:
% svn stat -u
* 6 .
A * 0 added
Head revision: 9
So I'd like to suggest that it ought to just display 'A' in this case.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Dec 6 08:27:26 2002