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

Re: svn:externals parser API

From: Stefan Sperling <stsp_at_elego.de>
Date: Tue, 21 Feb 2012 23:50:54 +0100

On Tue, Feb 21, 2012 at 10:26:34PM +0100, Nikolaus Demmel wrote:
> Hi,
>
> this is my first post to this list and I'm not subscribed, so please CC
> me when answering.
>
> I'm investigating how to improve using git-svn with svn-externals,
> either with an additional script or directly in within git. In any case
> I would need git-svn to display the externals. There is "git svn
> propget", but there is no "recursive" parameter yet. A long time ago
> "git svn show-externals" was written, which gets the svn:externals
> property recursively and does some very crude processing. Unfortunetly
> it can only deal with the pre 1.5 format for svn:externals.
>
> Since external definitions are quite complex by now, with the old and
> new format, with comments and empty lines, (peg) revisions, relative and
> absolute URLs, it would be nice to get a parsed form of these externals
> with the URLs already resolved and the order always the same
> irrespective of whether the actual definitions are in the old or the new
> format.
>
> The obvious way to get those parse external definitions would be through
> the language bindings. I looked at the python bindings for example, but
> didn't find anything of the likes. In the case of git-svn, they use the
> perl bindings, but I guess it is a similar story there.
>
> I have the following questions:
>
> 1) Is there a way to leverage an existing svn:externals parser through
> the language bindings (and I have been unable to find it)?
>
> 2) If not, would it be easy to add this to the language bindings?
>
> A quick look at hgsubversion indicates that their handling of
> svn:externals is far more sophisticated that that of git-svn at the
> moment, but even in their code they mention that they don't support
> escaping of special characters in paths, like spaces for example (this
> was introduced in svn 1.6, I think).
>
> So in any case it would be hard and error prone, if every tool that
> wants to deal with externals has to write a parser itsself. Also, the
> documentation on the special cases and all the details is not so easy to
> find. The svn book explains it from a user perspective, but doesn't give
> a full specification of the exact format. The most accurate and concise
> description is maybe "svn help propget", but even there some things are
> missing, e.g. that empty lines and trailing/perceding white space seems
> to be allowed etc.
>
> I hope someone can give me some insight in the matter. Currently the
> simplest way to get my svn repository with many externals working nicely
> in git, is to first use hgsubversion to create a mercurial repo and then
> export that to git using hggit. I hope thats not the end of the story...

I think svn_wc_parse_externals_description3() should do what you need.
Does this help you?

The function is mapped in the python bindings:

>>> import svn.wc
>>> svn.wc.svn_wc_parse_externals_description3
<function svn_wc_parse_externals_description3 at 0x20779a758>

Below is the C API documentation:

/**
 * If @a externals_p is non-NULL, set @a *externals_p to an array of
 * #svn_wc_external_item2_t * objects based on @a desc.
 *
 * If the format of @a desc is invalid, don't touch @a *externals_p and
 * return #SVN_ERR_CLIENT_INVALID_EXTERNALS_DESCRIPTION. Thus, if
 * you just want to check the validity of an externals description,
 * and don't care about the parsed result, pass NULL for @a externals_p.
 *
 * The format of @a desc is the same as for values of the directory
 * property #SVN_PROP_EXTERNALS. Look there for more details.
 *
 * If @a canonicalize_url is @c TRUE, canonicalize the @a url member
 * of those objects. If the @a url member refers to an absolute URL,
 * it will be canonicalized as URL consistent with the way URLs are
 * canonicalized throughout the Subversion API. If, however, the
 * @a url member makes use of the recognized (and proprietary)
 * relative URL syntax, "canonicalization" is a less easily-defined
 * concept which may even result in munging the relative URL syntax
 * beyond recognition. You've been warned.
 *
 * Allocate the table, keys, and values in @a pool.
 *
 * Use @a parent_directory only in constructing error strings.
 *
 * @since New in 1.5.
 */
svn_error_t *
svn_wc_parse_externals_description3(apr_array_header_t **externals_p,
                                    const char *parent_directory,
                                    const char *desc,
                                    svn_boolean_t canonicalize_url,
                                    apr_pool_t *pool);
Received on 2012-02-21 23:51:33 CET

This is an archived mail posted to the Subversion Users mailing list.