You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Martin Pool <mb...@sngrel5.hp.com> on 2002/12/06 07:17:31 UTC
svn stat on new files
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
total 24
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
? extra
nonexistent
'svn stat -u' on a file that has been added but not committed gives an
error:
% svn stat added
A 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
? extra
Head revision: 9
So I'd like to suggest that it ought to just display 'A' in this case.
Thanks,
--
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn stat on new files
Posted by Benjamin Pflugmann <be...@pflugmann.de>.
Hello.
Maybe I am misreading something, but I cannot see either concern with
the patch.
On Fri 2002-12-06 at 13:36:29 -0600, Ben Collins-Sussman wrote:
>
> Ugh, read the log and diff for r3746. It looks like your change is
> going to undo that fix...?
Before the patch, it was like (shortened)
/* only if entry == NULL, i.e. unversioned items */
stat->text_status = svn_wc_status_none;
if (path_kind != svn_node_none)
stat->text_status = svn_wc_status_unversioned;
which results in ("sws_" as shorthand for "svn_wc_status_")
path_kind |
---------------+-----------------
svn_node_none | sws_none
other | sws_unversioned
r3746 changed it so that it becomes
stat->text_status = svn_wc_status_none;
if (path_kind != svn_node_none)
if (is_ignored)
stat->text_status = svn_wc_status_none;
else
stat->text_status = svn_wc_status_unversioned;
path_kind | !is_ignored | is_ignored
---------------+-----------------+-------------
svn_node_none | sws_none | sws_none
other | sws_unversioned | sws_none
In other words: The behaviour has changed for entries which really
exist on disk (path_kind != svn_node_none). If they are on the
ignore-list (that is what is_ignored effectively means, AFAICT), they
have sws_none, beforehand they had sws_unversioned. That is in order
to enable clients to tell the difference when a full status output is
done.
Matt's suggested patch changes this into:
stat->text_status = svn_wc_status_unversioned;
if (is_ignored)
stat->text_status = svn_wc_status_none;
path_kind | !is_ignored | is_ignored
---------------+-----------------+-------------
svn_node_none | sws_unversioned | sws_unversioned
other | sws_unversioned | sws_none
It's obvious that the change of r3746 is still there: it affected
existing nodes, i.e. the "other" row, while Matt's patch affects
non-existing nodes (the "svn_node_none" row). r3746 is about
differentiating between the !is_ignored and is_ignored columns, which
always had equal values in the svn_node_none row (before and after the
current patch).
[...]
On Fri 2002-12-06 at 13:04:00 -0600, Karl Fogel wrote:
> Matt Kraai <kr...@alumni.cmu.edu> writes:
> > Here is a patch which does so. OK to commit?
>
> I think you're solving a different [non]-problem.
>
> This isn't about explicitly ignored files;
See above. His change is neutral regarding is_ignored (by this I mean,
it's the same regardless of the value of is_ignored).
Or do you mean, the status should be sws_none for the cell
(svn_node_none and is_ignored)?
> it's about non-existent filenames being given as arguments to an svn
> command.
Well, it does indeed simply change all non-existent files to
unversioned and therefore implicitly to display a "?" in the command
line client.
A completely different point is whether that new meaning is
consistent. At the start sws_none meant "non-existing". Through r3764
it became "non-existing or ignored". And now it becomes "existing and
ignored". (All also imply "not versioned", of course).
Whereas sws_unversioned started with (all implying "not versioned",
still) "existing", with r3746 it became "non-ignored and existing"
and now would be "non-ignored or non-existing".
Regarding these changes, it looks to me as if the meaning of these
values is simply overloaded and maybe it would be more reasonable to
introduce new values of svn_wc_status_*, instead of picking unused
corner cases and giving them new meanings.
What would the ideal table look like?
path_kind | !is_ignored | is_ignored
---------------+---------------------+-------------
svn_node_none | unversioned/missing | missing
other | unversioned | ignored
You can simply use sws_none instead of missing; I only wanted to avoid
confusion with its already overloaded use from above. As you see, I am
not sure, if unversioned or missing should win in one cell. I can see
the case for either. Just imagine the client prints "I" for ignored,
"-" for missing and "?" for unversioned. Currently the client would
display "?" for both, missing and unversioned.
Hope I did not discuss something different than was meant. ;-)
Bye,
Benjamin.
Re: svn stat on new files
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Matt Kraai <kr...@alumni.cmu.edu> writes:
> Here is a patch which does so. OK to commit?
I think you're solving a different [non]-problem.
This isn't about explicitly ignored files; it's about non-existent
filenames being given as arguments to an svn command. (Re-read Martin
Pool's message, maybe?)
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn stat on new files
Posted by Branko Čibej <br...@xbc.nu>.
Nuutti Kotivuori wrote:
>Branko wrote:
>
>
>>The funny thing is that if you use re.match(str, N), where N>0, an
>>expression starting with "^" will never match -- because "^" matches
>>the beginning of a string
>>
>>
>
>...or after a newline, depending on the semantics of that particular
>regular expression engine (and flags given to it, if it owns such things).
>
Of course, but I didn't want to confuse people with multiline matches. :-)
So yes,
re.compile("^", re.M).match("\n", 1)
does in fact match the empty string jst after the newline.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn stat on new files
Posted by Nuutti Kotivuori <na...@iki.fi>.
Branko wrote:
> The funny thing is that if you use re.match(str, N), where N>0, an
> expression starting with "^" will never match -- because "^" matches
> the beginning of a string
...or after a newline, depending on the semantics of that particular
regular expression engine (and flags given to it, if it owns such things).
> , and you're telling re.match to start beyond that. :-)
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn stat on new files
Posted by Branko Čibej <br...@xbc.nu>.
Kirby C. Bohling wrote:
>Karl,
>
> From my limited understanding of Python, the regular expression has to
>match the entire input, partial matches don't count.
>
No, that's wrong. The difference between re.match and re.search is that
re.match is implicitly anchored at the beginning of the search string,
while re.search is not.
> The method search
>(I believe it's search, I know there is another similar method) is grep
>like, and behaves the way you describe. Basically match prepends ^, and
>appends $ after the regex if I understand correctly.
>
No. Read the docs in the "re" module carefully. They're a bit confucing,
I admit, but the examples help you understand what's going on.
The funny thing is that if you use re.match(str, N), where N>0, an
expression starting with "^" will never match -- because "^" matches the
beginning of a string, and you're telling re.match to start beyond that. :-)
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn stat on new files
Posted by "Kirby C. Bohling" <kb...@birddog.com>.
Karl,
From my limited understanding of Python, the regular expression has to
match the entire input, partial matches don't count. The method search
(I believe it's search, I know there is another similar method) is grep
like, and behaves the way you describe. Basically match prepends ^, and
appends $ after the regex if I understand correctly.
If I don't, I'm sure 3 people will correctly :-) This bites me
everytime I use it, so I've learned, that search is what I want, and
match isn't.
Kirby
On Fri, 2002-12-06 at 17:07, Karl Fogel wrote:
> Matt Kraai <kr...@alumni.cmu.edu> writes:
> > I think using match implies a leading "^":
> >
> > If zero or more characters at the beginning of string match the
> > regular expression pattern, return a corresponding MatchObject
> > instance.[1]
>
> You're right:
>
> $ python2
> Python 2.1 (#1, Apr 21 2001, 18:56:55)
> [GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2
> Type "copyright", "credits" or "license" for more information.
> >>> import re
> >>> re.match("newfile", "newfile")
> <SRE_Match object at 0x81300b0>
> >>> re.match("newfile", " newfile")
> >>>
>
> Surprising! (To me, anyway).
>
> -K
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
Real Programmers view electronic multimedia files with a hex editor.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn stat on new files
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Matt Kraai <kr...@alumni.cmu.edu> writes:
> I think using match implies a leading "^":
>
> If zero or more characters at the beginning of string match the
> regular expression pattern, return a corresponding MatchObject
> instance.[1]
You're right:
$ python2
Python 2.1 (#1, Apr 21 2001, 18:56:55)
[GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import re
>>> re.match("newfile", "newfile")
<SRE_Match object at 0x81300b0>
>>> re.match("newfile", " newfile")
>>>
Surprising! (To me, anyway).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn stat on new files
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Btw, if that test behaves as you expected it to, +1 on checking it in.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn stat on new files
Posted by Matt Kraai <kr...@alumni.cmu.edu>.
On Fri, Dec 06, 2002 at 04:40:03PM -0600, Karl Fogel wrote:
> Matt Kraai <kr...@alumni.cmu.edu> writes:
> > Is the following test what you had in mind?
>
> That regexp
>
> > + for line in stat_output:
> > + if re.match(" +newfile", line):
> > + status = 0
>
> will match both "? newfile" and " newfile". Maybe you want
>
> re.match("^ +newfile", line):
>
> instead, or something like that?
I think using match implies a leading "^":
If zero or more characters at the beginning of string match the
regular expression pattern, return a corresponding MatchObject
instance.[1]
Matt
1. http://www.python.org/doc/current/lib/node99.html#l2h-722
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn stat on new files
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Matt Kraai <kr...@alumni.cmu.edu> writes:
> Is the following test what you had in mind?
That regexp
> + for line in stat_output:
> + if re.match(" +newfile", line):
> + status = 0
will match both "? newfile" and " newfile". Maybe you want
re.match("^ +newfile", line):
instead, or something like that?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn stat on new files
Posted by Matt Kraai <kr...@alumni.cmu.edu>.
On Fri, Dec 06, 2002 at 01:46:09PM -0600, Karl Fogel wrote:
> Philip Martin <ph...@codematters.co.uk> writes:
> > Which means that we don't have a regression test for the r3746
> > behaviour, or that Matt forgot to run the tests...
>
> Maybe we should ask Matt to write a regression test for that :-).
>
> Ahem.
Is the following test what you had in mind?
Matt
Index: subversion/tests/clients/cmdline/stat_tests.py
===================================================================
--- subversion/tests/clients/cmdline/stat_tests.py (revision 4008)
+++ subversion/tests/clients/cmdline/stat_tests.py (working copy)
@@ -243,6 +243,33 @@
return 0
+def status_blank_for_ignored_file(sbox):
+ "status blank for ignored file"
+
+ if sbox.build():
+ return 1
+
+ wc_dir = sbox.wc_dir
+ was_cwd = os.getcwd()
+
+ os.chdir(wc_dir)
+
+ svntest.main.file_append('newfile', 'this is a new file')
+ svntest.main.run_svn(None, 'propset', 'svn:ignore', 'newfile', '.')
+ stat_output, err_output = svntest.main.run_svn(None, 'status', '--no-ignore',
+ '.')
+ if err_output:
+ return 1
+ status = 1
+ for line in stat_output:
+ if re.match(" +newfile", line):
+ status = 0
+
+ os.chdir(was_cwd)
+
+ return status
+
+
########################################################################
# Run the tests
@@ -255,6 +282,7 @@
status_missing_file,
status_type_change,
status_with_new_files_pending,
+ status_blank_for_ignored_file,
]
if __name__ == '__main__':
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn stat on new files
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Philip Martin <ph...@codematters.co.uk> writes:
> Which means that we don't have a regression test for the r3746
> behaviour, or that Matt forgot to run the tests...
Maybe we should ask Matt to write a regression test for that :-).
Ahem.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn stat on new files
Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Collins-Sussman <su...@collab.net> writes:
> Ugh, read the log and diff for r3746. It looks like your change is
> going to undo that fix...?
Which means that we don't have a regression test for the r3746
behaviour, or that Matt forgot to run the tests...
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn stat on new files
Posted by Ben Collins-Sussman <su...@collab.net>.
Ugh, read the log and diff for r3746. It looks like your change is
going to undo that fix...?
Matt Kraai <kr...@alumni.cmu.edu> writes:
> On Fri, Dec 06, 2002 at 02:03:03PM +0000, Philip Martin wrote:
> > Ben Collins-Sussman <su...@collab.net> writes:
> >
> > > Martin Pool <mb...@sngrel5.hp.com> writes:
> > >
> > > > 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.
> > >
> > > I agree, 'svn stat nonexistent-file' should give an error. It's a bug
> > > that it prints the filename instead... it makes no sense. We should
> > > file an issue on that.
> >
> > I prefer Martin's suggestion that it print '?'. If the file does not
> > exist, and does not have a .svn entry, then it is not under revision
> > control and '?' is the right status. (If it does have a .svn entry
> > then '!' will be dispayed.) I also suspect it will make 'svn status'
> > easier to use if it doesn't generate an error in this case.
>
> Here is a patch which does so. OK to commit?
>
> Matt
>
> * subversion/libsvn_wc/status.c
> (assemble_status): Set the text_status to svn_wc_status_unversioned
> for a non-extant file.
>
> Index: subversion/libsvn_wc/status.c
> ===================================================================
> --- subversion/libsvn_wc/status.c (revision 4008)
> +++ subversion/libsvn_wc/status.c (working copy)
> @@ -133,7 +133,7 @@
> /* return a blank structure. */
> stat = apr_pcalloc (pool, sizeof(*stat));
> stat->entry = NULL;
> - stat->text_status = svn_wc_status_none;
> + stat->text_status = svn_wc_status_unversioned;
> stat->prop_status = svn_wc_status_none;
> stat->repos_text_status = svn_wc_status_none;
> stat->repos_prop_status = svn_wc_status_none;
> @@ -141,18 +141,10 @@
> stat->copied = FALSE;
> stat->switched = FALSE;
>
> - /* If this path has no entry, but IS present on disk, it's
> - unversioned. If this file is being explicitly ignored (due
> - to matching an ignore-pattern), the text_status is set to
> - svn_wc_status_none. Otherwise the text_status is set to
> - svn_wc_status_unversioned. */
> - if (path_kind != svn_node_none)
> - {
> - if (is_ignored)
> - stat->text_status = svn_wc_status_none;
> - else
> - stat->text_status = svn_wc_status_unversioned;
> - }
> + /* If this file is being explicitly ignored (due to matching an
> + ignore-pattern), the text_status is set to svn_wc_status_none. */
> + if (is_ignored)
> + stat->text_status = svn_wc_status_none;
>
> *status = stat;
> return SVN_NO_ERROR;
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn stat on new files
Posted by Matt Kraai <kr...@alumni.cmu.edu>.
On Fri, Dec 06, 2002 at 02:03:03PM +0000, Philip Martin wrote:
> Ben Collins-Sussman <su...@collab.net> writes:
>
> > Martin Pool <mb...@sngrel5.hp.com> writes:
> >
> > > 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.
> >
> > I agree, 'svn stat nonexistent-file' should give an error. It's a bug
> > that it prints the filename instead... it makes no sense. We should
> > file an issue on that.
>
> I prefer Martin's suggestion that it print '?'. If the file does not
> exist, and does not have a .svn entry, then it is not under revision
> control and '?' is the right status. (If it does have a .svn entry
> then '!' will be dispayed.) I also suspect it will make 'svn status'
> easier to use if it doesn't generate an error in this case.
Here is a patch which does so. OK to commit?
Matt
* subversion/libsvn_wc/status.c
(assemble_status): Set the text_status to svn_wc_status_unversioned
for a non-extant file.
Index: subversion/libsvn_wc/status.c
===================================================================
--- subversion/libsvn_wc/status.c (revision 4008)
+++ subversion/libsvn_wc/status.c (working copy)
@@ -133,7 +133,7 @@
/* return a blank structure. */
stat = apr_pcalloc (pool, sizeof(*stat));
stat->entry = NULL;
- stat->text_status = svn_wc_status_none;
+ stat->text_status = svn_wc_status_unversioned;
stat->prop_status = svn_wc_status_none;
stat->repos_text_status = svn_wc_status_none;
stat->repos_prop_status = svn_wc_status_none;
@@ -141,18 +141,10 @@
stat->copied = FALSE;
stat->switched = FALSE;
- /* If this path has no entry, but IS present on disk, it's
- unversioned. If this file is being explicitly ignored (due
- to matching an ignore-pattern), the text_status is set to
- svn_wc_status_none. Otherwise the text_status is set to
- svn_wc_status_unversioned. */
- if (path_kind != svn_node_none)
- {
- if (is_ignored)
- stat->text_status = svn_wc_status_none;
- else
- stat->text_status = svn_wc_status_unversioned;
- }
+ /* If this file is being explicitly ignored (due to matching an
+ ignore-pattern), the text_status is set to svn_wc_status_none. */
+ if (is_ignored)
+ stat->text_status = svn_wc_status_none;
*status = stat;
return SVN_NO_ERROR;
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn stat on new files
Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Collins-Sussman <su...@collab.net> writes:
> Martin Pool <mb...@sngrel5.hp.com> writes:
>
> > 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.
>
> I agree, 'svn stat nonexistent-file' should give an error. It's a bug
> that it prints the filename instead... it makes no sense. We should
> file an issue on that.
I prefer Martin's suggestion that it print '?'. If the file does not
exist, and does not have a .svn entry, then it is not under revision
control and '?' is the right status. (If it does have a .svn entry
then '!' will be dispayed.) I also suspect it will make 'svn status'
easier to use if it doesn't generate an error in this case.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn stat on new files
Posted by Ben Collins-Sussman <su...@collab.net>.
Martin Pool <mb...@sngrel5.hp.com> writes:
> 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.
I agree, 'svn stat nonexistent-file' should give an error. It's a bug
that it prints the filename instead... it makes no sense. We should
file an issue on that.
> 'svn stat -u' on a file that has been added but not committed gives an
> error:
>
> % svn stat added
> A added
> % svn stat -u added
> svn: Filesystem has no item
> svn: file not found: transaction `d', path `/trunk'
Ah, this is a bug as well. The -u flag is doing a dry-run of "svn
update added" under the hood. And as expected, the server says that
the item is not found in the repository. I suspect that 'svn status'
should specifically trap this error and ignore it... i.e. just not add
any additional out-of-date info. 'svn stat added' and 'svn -u added'
would print just "A" in this case.
> 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.
Huh? I'm not following your last sentence. The -u flag means, "add
out-of-date information." If somebody else has already added a file
by the same name, then the filesystem will see it, and status will
show:
% svn stat added
A * 0 newfile
The asterisk means that your file, even though it's only scheduled for
addition, is already out-of-date. Somebody beat you to the punch.
> 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.
Again, I'm not understanding the problem. 'svn st' has exactly three
output formats. It took no less than two months of list discussion to
design this. :-)
1. 'svn st' only shows local items that are interesting. It uses the
"short" format: the standard 5 columns (MMLS+) and a pathname.
2. 'svn st -u' shows local items that are interesting, and adds
out-of-date information. It uses the "medium" format: the
standard 5 columns, an out-of-date (*) column, a working-rev
column, and a pathname.
3. 'svn st -v' shows every single item, interesting or not. It uses
the "long" format: standard 5 columns, out-of-date column (if -u
was given), working-rev, last-changed-rev, last-author, pathname.
This is all documented in 'svn help status'.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org