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

Re: svn diff: properties?

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2001-09-07 00:10:59 CEST

"C. Scott Ananian" <cananian@lesser-magoo.lcs.mit.edu> writes:

> I think that, to maximally enable collaboration, it would be great if we
> provided a sort of patch++ format that could handle these sorts of
> contributions. One possibility would be to create special 'filenames' for
> the properties (say, foo/svn:ignore for a property of foo) and pipe the
> patch output through svn. svn could dump the properties to the special
> files, then run 'normal' patch, then re-slurp the properties from the
> special files and clean up.

Look at my previous mail about editors. We already have an XML
"patch++" format. It essentially describes everything that an
`editor' does when editing a tree. It was all we used to use for
Milestone 1 -- we had no other way to test the client, other than to
commit to XML patch files, and update from them.

We expected that someday (it's been a year!) people might use this
format to post patches to mailing lists. :-)

Look in libsvn_delta, xml_output.c, xml_parse.c.

Also look at our tests in `make check': specifically, the two bourne
scripts in tests/clients/cmdline/xmltests/.

Here's the relevant part of svn_delta.h:

/* Creates an editor which outputs XML delta streams to OUTPUT. On
   return, *EDITOR and *EDITOR_BATON will be set to the editor and its
   associate baton. The editor's memory will live in a sub-pool of
   POOL. */
svn_error_t *
svn_delta_get_xml_editor (svn_stream_t *output,
                          const svn_delta_edit_fns_t **editor,
                          void **edit_baton,
                          apr_pool_t *pool);

/* Given a precreated svn_delta_edit_fns_t EDITOR, return a custom xml
   PARSER that will call into it (and feed EDIT_BATON to its
   callbacks.) Additionally, this XML parser will use BASE_PATH and
   BASE_REVISION as default "context variables" when computing ancestry
   within a tree-delta. */
svn_error_t *svn_delta_make_xml_parser (svn_delta_xml_parser_t **parser,
                                         const svn_delta_edit_fns_t *editor,
                                         void *edit_baton,
                                         svn_stringbuf_t *base_path,
                                         svn_revnum_t base_revision,
                                         apr_pool_t *pool);

/* Destroy an svn_delta_xml_parser_t when finished with it. */
void svn_delta_free_xml_parser (svn_delta_xml_parser_t *parser);

/* Push LEN bytes of xml data in BUFFER at SVN_XML_PARSER. As xml is
   parsed, EDITOR callbacks will be executed (using context variables
   and batons that were used to create the parser.) If this is the
   final parser "push", ISFINAL must be set to true (so that both
   expat and local cleanup can occur). */
svn_error_t *
svn_delta_xml_parsebytes (const char *buffer, apr_size_t len, int isFinal,
                          svn_delta_xml_parser_t *svn_xml_parser);

/* Reads an XML stream from SOURCE using expat internally, validating
   the XML as it goes (according to Subversion's own tree-delta DTD).
   Whenever an interesting event happens, it calls a caller-specified
   callback routine from EDITOR.
   Once called, it retains control and "pulls" data from SOURCE
   until either the stream runs out or an error occurs. */
svn_error_t *svn_delta_xml_auto_parse (svn_stream_t *source,
                                       const svn_delta_edit_fns_t *editor,
                                       void *edit_baton,
                                       svn_stringbuf_t *base_path,
                                       svn_revnum_t base_revision,
                                       apr_pool_t *pool);

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:40 2006

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.