On a selfish note, we do not get to process stderr in the xslt consumer of
the output. I would further go out on a limb and say that most consumers of
XML would benefit from the errors being in band vs. out of band.
<info/> tells enough or better yet
<info>
<error msg="svn: '.' is not a working copy"/>
</info>
Both are nice, first is trivial.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Sr. Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you
have received it in error, purge the message from your system and
notify the sender immediately. Any other use of the email by you
is prohibited.
-----Original Message-----
From: Peter Lundblad [mailto:plundblad@google.com]
Sent: Tuesday, February 13, 2007 3:04
To: Daniel Rall
Cc: Jason Pyeron; dev@subversion.tigris.org
Subject: Re: svn status -u --xml
Daniel Rall writes:
> Hmm, but not *which* path, if you list several, some of which are
> under VC, some of which are not. The behavior for non --xml mode is
> "stop and error out as soon as you hit a path not under VC":
>
There's no different between with and without --xml regarding info.
It treats "not a working copy" as an error instead of as a warning as
status does. I think there's still an old issue regarding our
inconsistency regarding this
We need to distinguish between the case where we emit a warning and continue
and the case were we bail. I think it makes sense to output well-formed
and valid XML in the former case. In the latter case it is going to be
more tricky since an error can happen anywhere.
A way to know if a directory is a working copy would be to just run
svn info on it, disregarding the output. If stderr is empty, you can be
sure
it is a working copy.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 13 16:04:07 2007