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

RE: Things I learned making cvs2svn work today

From: Daniel Berlin <dan_at_dberlin.org>
Date: 2002-02-03 02:21:23 CET

On Sun, 3 Feb 2002, Sander Striker wrote:

> [...]
> > I'll post the additions to the bindings necessary to use streams with
> > python file objects (which you need to construct proper deltas from
> > python), and the cvs2svn.py diffs, in a few minutes.
> >
> > For kicks, i also made the svn_string* conversions requiring a
> > stringpool work .
> > This enables one to build the svn_client and svn_wc bindings.
> > For svn_stringbuf_t (including arrays of svn_stringbuf's) input, we
> > require a (string, pool) tuple be passed in, and use that pool.
> > For svn_string_t member storage (where it wants to svn_string_dup a
> > string), I just have it use an apr debugging function called apr_find_pool
> Buzzz, no can do. That function is not available without --enable-pool-debug.
> And requiring that seems a bit of a tough requirement.
That leaves the following options:
1. Make a global stringpool just to make constant strings
to store in keyword structures (this is the only place that's using it).

2. Make it the programmer's responsibility to make sure the strings
they set in that structure don't change (duplicating them if necessary
before setting them).

3. Make up c functions that set and get the members of that structure
that take a pool argument, and tell swig not to generate setters/getters
for that structure on it's own.

4. Don't expose the keyword/eol conversion/expansion stuff to the binding.

I'm not quite sure what the best solution is here.
Though i'm pretty sure this is all the possibilities.
For right now (IE for the purposes of producing diffs to send to the
mailing list), i'll do #4.


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:37:03 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.