On Sun, 15 May 2005 alexander@collab.net wrote:
> On Wed, 2005-05-11 at 22:46 +0200, Peter N. Lundblad wrote:
> > On Mon, 9 May 2005 alexander@collab.net wrote:
> >
> > > @@ -119,17 +167,26 @@
> > > sb.show_last_committed = opt_state->verbose;
> > > sb.skip_unrecognized = opt_state->quiet;
> > > sb.repos_locks = opt_state->update;
> > > + sb.xml_mode = opt_state->xml;
> > > sb.pool = subpool;
> > > - SVN_ERR (svn_client_status2 (NULL, target, &rev, print_status,
> > > &sb,> > +
> > > + SVN_ERR (svn_client_status3 (NULL, target, &rev, print_status,
> > > &sb,>
> > Here, you can get the HEAD revision of the repository through the
> > first argument.
>
> Its a great suggestion to use first argument to get the HEAD revision
> and later printing 'status against' in XML format. But still we need
> some mechanics either in libsvnclient/status.c or in
> client/cmdline/notify.c, for not printing the "Status Against
> revision" (in traditional mode) while requesting for XML.
Yes, but keep it in the notification baton then. Even better, turn off
notification completely be setting notify_func2 in the client context to
NULL in this case. You don't want any notification on stdout when
generating XML.
> > >
> > > + /* If we're running the `status' subcommand with xml option, then
> > > + verbose or detailed mode is activated */
> > > + if ((opt_state.xml) && subcommand->cmd_func == svn_cl__status)
> > > + opt_state.verbose = TRUE;
> > > +
> > Why do you need to set this here?
>
> No need to set this here. If we create a new function for
> svn_cl__print_status (some thing like svn_cl__print_status_xml), this
> can be handled there.
>
I think that'd be cleaner.
>
> > <!ENTITY % BOOL "(true | false) false">
> >
> > <!ELEMENT status (target*)>
> >
> > <!ELEMENT target (entry*, against?>>
> > <!ATTLIST target
> > path CDATA #REQRURED> <!-- target path -->
> >
> > <!ELEMENT entry (wc-status, repos-status?, wc-lock?, repos-lock?)>
> >
> > <!ELEMENT wc-status (lock?)>
> > <!ATTLIST wc-status
> > item (added | conflicted | deleted | merged | ignored | modified |
> > replaced | external | unversioned | incomplete | obstructed)
> > #IMPLIED <!-- Item status: no value means unmodified. -->
> > props (conflicted | modified) #IMPLIED <!-- Prop status: no value
> > means unmodified. -->
> > wc-locked %BOOL; <!-- WC dir locked? -->
> > copied %BOOL; <!-- Add with history? -->
> > switched %BOOL; <!-- Item switched -->
> > >
> >
> > <!ELEMENT repos-status (lock?)>
> > <!ATTLIST repos-status
> > item (added | deleted | modified | replaced) #IMPLIED
> > <!-- NO value means no modifications. -->
> > props (modified) #IMPLIED
> > <!-- No value means ... -->
> >
> > <!-- Lock info stored in WC or repos. -->
> > <!ELEMENT lock (token, owner, comment?, created, expires?)>
> >
> > <!ELEMENT token (#PCDATA)> <!-- Lock token URI. -->
> > <!ELEMENT owner (#PCDATA)> <!-- Lock owner. -->
> > <!ELEMENT comment (#PCDATA)> <!-- Lock Comment. -->
> > <!ELEMENT created (#PCDATE)> <!-- Creation date in ISO format. -->
> > <!ELEMENT expires (#PCDATA)> <!-- Expiration date in ISO format. -->
> >
> > <!ELEMENT against EMPTY>
> > <!ATTLIST against revision CDATA #REQUIRED>
> >
> > This is not tested or anything, so it might contain errors, but yoiu
> > get the idea. Do you like it?
> >
> Seems ok to me ( not gone in-depth), but why we need a complicated
> DTD, why don't we keep it simple ? after all XML in meant for parsing :)
>
Please tell me what you think is complicated in the above. It adds more
info than the column-based output provides. I think that's good because
the information is available and can easily be filtered by the receiving
application. I created some hierarchical structure to make the info easier
to get. Since many fields have a limited set of values, I defined them as
enumerated attributes, which I think is good since it is an explicit
formal definition. I tried to make the markup descriptive so it is easier
to understand for a human (who has to design the parser) and I don't think
verbosity is a problme here.
Note that this is not a "why my design is best" kind of reply. I just
wanted to clarify my reasons, which I should have done in the previous
mail. (And note that the above is invalid XML, since comments aren't
allowed inside attribut lists.)
Hope this clarifies,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 16 21:51:00 2005