On Sat, 2 Feb 2002, Daniel Berlin wrote:
> I got pissed off enough at CVS today (I work on GCC constantly, and the
> gcc development policy is now to create branches rather than keep large
> experimental things on the mainline, but disabled. So I have about 8 or
> nine trees checked out, and of course, updating/working with each one and
> managing merges/etc is just not fun) that i figured i'd stop lurking and
> do something useful towards getting rid of it.
> To that end, and knowing python pretty well, I took the absolute latest
> cvs2svn, and made it actually able to convert the mainline branch of gcc's
> cvs repository (doing all the branches is actually only a few more lines
> of code, to walk the descendant branches, do the right copies, etc).
>
> Most of it was fighting swig and various bugs in the version needed (I was
> using 1.3.10), that appear to cause it to ignore typemaps with the ignore
> keyword (which is really supposed to ignore the argument passed in), and
> not generate the code for them. Which of course, causes you to end up
> with unitialized variables being passed to critical functions (say,
> svn_fs_apply_textdelta).
> Using a kludgy workaround, i was able to call the functions i needed to
> work with the repository.
This bug is now fixed in swig 1.3.11 (It was doing exactly as i had
thought, which is only output the code for the first ignore typemap it
saw, because it would ask for the next default typemap sibling, rather
than ignore typemap sibling), which was released today, so the kludges are
no longer needed.
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
to get the pool for the svn_string_t object, until we think of a better
way to do this (since it's not python input it's using, but an already
constructed svn_string_t, we can't require a tuple)
It's either that, or some kind of global python stringpool just to dup the
strings, which seems a bit silly.
--Dan
---------------------------------------------------------------------
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