On Wed, 2005-05-11 at 22:46 +0200, Peter N. Lundblad wrote:
> On Mon, 9 May 2005 alexander@collab.net wrote:
>
> Here we go:
>
> > Index: subversion/include/svn_wc.h
> > ===================================================================
> > --- subversion/include/svn_wc.h (revision 13821)
> > +++ subversion/include/svn_wc.h (working copy)
> > @@ -543,7 +543,9 @@
> > svn_wc_notify_failed_lock,
> >
> > /** @since New in 1.2. Failed to unlock a path. */
> > - svn_wc_notify_failed_unlock
> > + svn_wc_notify_failed_unlock,
> > +
> > + svn_wc_notify_status_xml_completed
>
> You don't need this. (See below)
>
> > } svn_wc_notify_action_t;
> >
...
> > @@ -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.
> >
> > + /* 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.
> <!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 :)
Thanks
-Alexander Thomas (AT)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 16 08:26:27 2005