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

Re: [PATCH] 'svn info --xml'

From: Alexander Thomas <alexander_at_collab.net>
Date: 2005-05-31 10:33:23 CEST

On Mon, 2005-05-30 at 22:31 +0100, Julian Foad wrote:

> > Index: subversion/clients/cmdline/dtd/info.dtd
> > ===================================================================
> > --- subversion/clients/cmdline/dtd/info.dtd (revision 0)
> > +++ subversion/clients/cmdline/dtd/info.dtd (revision 0)
> > @@ -0,0 +1,54 @@
> > +<!-- XML DTD for Subversion command-line client output. -->
> > +
> > +<!-- For "svn info" -->
> > +<!ELEMENT info (target*)>
> > +
> > +<!ELEMENT target (entry*)>
>
> The "info" command's output is not (logically) grouped according to how the
> targets were specified on the command line. Each item for which information is
> printed is a self-contained item. So there is no need for a "target" element:
> <!ELEMENT info (entry*)>

No objection in removing "target". But before that let me say my
conclusion about this.

Info command support multiple target and also output multiple entries
for a single target (try 'svn info *'). So in such cases I think its
better to keep "target" in-tact.

> > +
> > +/* prints svn info in xml mode to standard out */
> > +static svn_error_t *
> > +print_info_xml (const char *target,
> > + const svn_info_t *info,
> > + apr_pool_t *pool)
> > +{
> > + const char *str_kind;
> > + svn_stringbuf_t *sb = svn_stringbuf_create ("", pool);
> > +
> > + switch (info->kind)
> > + {
> > + case svn_node_file:
> > + str_kind = "file";
> > + break;
> > +
> > + case svn_node_dir:
> > + str_kind = "directory";
> > + break;
> > +
> > + case svn_node_none:
> > + str_kind = "none";
> > + break;
> > +
> > + case svn_node_unknown:
> > + default:
>
> The "default" case should throw an error, I should think. (I see you just
> copied this from the existing non-XML code.)

OK I will change this to abort()
>
> > + str_kind = "unknown";
> > + break;
> > + }
> Would it make sense to factor out this node-kind-to-text conversion and use it
> for both the XML and plain-text outputs? Also other enum-to-text conversions
> below.
Yep I agree, What about creating two separate function for schedule and
node-kind enums-to-text conversion ?

-Alexander Thomas (AT)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 31 10:33:35 2005

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.