You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Kouhei Sutou <ko...@cozmixng.org> on 2005/01/04 10:15:40 UTC
[PATCH] Ruby SWIG-based bindings
Hi,
I'm writing Ruby SWIG-based bindings.
http://pub.cozmixng.org/~kou/diff/svn-add-ruby-20050104.diff
This is not complete yet. But some examples work:
* tools/examples/svnshell.rb: Ruby version of
tools/examples/svnshell.py.
* tools/examples/svnlook.rb: Ruby version of
tools/examples/svnlook.py.
I want to administrate my codes by version control system.
I'm afraid of loosing my codes by human error.
Could you let me use http://svn.collab.net/repos/ to do?
--
kou
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Ruby SWIG-based bindings
Posted by Kouhei Sutou <ko...@cozmixng.org>.
Hi,
In <41...@electricjellyfish.net>
"Re: [PATCH] Ruby SWIG-based bindings" on Tue, 04 Jan 2005 22:08:53 -0500,
Garrett Rooney <ro...@electricjellyfish.net> wrote:
> >>>I'm writing Ruby SWIG-based bindings.
> >>> http://pub.cozmixng.org/~kou/diff/svn-add-ruby-20050104.diff
> >
> >>First of all, there seem to be some parts of the diff that change things
> >>that aren't specific to the ruby bindings,
> >
> > Is it swapping %include position for #include position? (See
> > the attachment.)
>
> That was one spot I noticed. Also you're changing the version of swig
> we compare against in swig.m4. Has that been tested with the other
> language bindings?
Really?
I had removed it from the diff showed at the above URL.
# Other diffs
# (http://pub.cozmixng.org/~kou/diff/svn-add-ruby-*.diff
# excluding http://pub.cozmixng.org/~kou/diff/svn-add-ruby-20050104.diff)
# have it. This is for me. I have only swig 1.3.22.
> > The codes generated by %include sometimes need some type
> > declarations. We have to use #include before the codes
> > generated by %include. So, I swapped %include position for
> > #include position.
>
> That seems reasonable. In general though when submitting a patch it's a
> good idea to format your log message in the style used by the rest of
> Subversion, see the "Writing log messages" section in the HACKING file.
Sorry.
I only wanted to explain you why I do. I was going to write
ChangeLog like format messages after you agree this.
> In this case you might have something like:
Thanks for showing me an example.
--
kou
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Ruby SWIG-based bindings
Posted by Kouhei Sutou <ko...@cozmixng.org>.
Hi,
In <20...@lyra.org>
"Re: [PATCH] Ruby SWIG-based bindings" on Wed, 5 Jan 2005 12:48:48 -0800,
Greg Stein <gs...@lyra.org> wrote:
> > The codes generated by %include sometimes need some type
> > declarations. We have to use #include before the codes
> > generated by %include. So, I swapped %include position for
> > #include position.
>
> I've found that it is rarely necessary to swap these around,
> especially given the fact that it worked before. I'd be interested in
> seeing the actual compile error that is produced.
First, it is a problem (maybe only) for Ruby-SWIG.
Ruby-SWIG generates prototype declarations of deconstructor
when SWIG finds struct declarations while processing
%include. And the prototype declarations uses `svn_*_t *' at
the argument declarations. This is the problem.
That is:
* the problem is not always happened. It is happened only
when there some struct declarations.
* the problem may be not happened other SWIG bindings.
Here is the compile error messages when *NOT* swap them in
svn_ra.i:
...
subversion/bindings/swig/ruby/svn_ra.c:578: error: parse error before '*' token
subversion/bindings/swig/ruby/svn_ra.c:581: error: parse error before '*' token
subversion/bindings/swig/ruby/svn_ra.c:584: error: parse error before '*' token
...
And the corresponding part of svn_ra.c:
swig_class cSvn_ra_reporter_t;
578: static void free_svn_ra_reporter_t(svn_ra_reporter_t *);
swig_class cSvn_ra_callbacks_t;
581: static void free_svn_ra_callbacks_t(svn_ra_callbacks_t *);
swig_class cSvn_ra_plugin_t;
584: static void free_svn_ra_plugin_t(svn_ra_plugin_t *);
...
601: #include "svn_ra.h"
#ifdef SWIGPYTHON
#include "swigutil_py.h"
#endif
#ifdef SWIGJAVA
#include "swigutil_java.h"
#endif
#ifdef SWIGPERL
#include "swigutil_pl.h"
#endif
#ifdef SWIGRUBY
#include "swigutil_rb.h"
#endif
...
> I would imagine one of two things are happening:
>
> * one of the SVN headers isn't including everything necessary for it
> to be self-consistent
>
> * one of the processed headers has an "extern" declaration in it. SWIG
> will write externs into the file where the %include happens, which
> can occur before the #include. Subversion headers should not be
> using the extern keyword, so we should fix them if this is the case.
So, my answer is the first one.
--
kou
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Ruby SWIG-based bindings
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Jan 05, 2005 at 11:50:51AM +0900, Kouhei Sutou wrote:
>...
> > First of all, there seem to be some parts of the diff that change things
> > that aren't specific to the ruby bindings,
>
> Is it swapping %include position for #include position? (See
> the attachment.)
>...
> The codes generated by %include sometimes need some type
> declarations. We have to use #include before the codes
> generated by %include. So, I swapped %include position for
> #include position.
I've found that it is rarely necessary to swap these around,
especially given the fact that it worked before. I'd be interested in
seeing the actual compile error that is produced.
I would imagine one of two things are happening:
* one of the SVN headers isn't including everything necessary for it
to be self-consistent
* one of the processed headers has an "extern" declaration in it. SWIG
will write externs into the file where the %include happens, which
can occur before the #include. Subversion headers should not be
using the extern keyword, so we should fix them if this is the case.
If it isn't one of the two above, then I'm very interested to see what
is happening.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Ruby SWIG-based bindings
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Kouhei Sutou wrote:
> Hi,
>
> In <41...@electricjellyfish.net>
> "Re: [PATCH] Ruby SWIG-based bindings" on Tue, 04 Jan 2005 12:37:46 -0500,
> Garrett Rooney <ro...@electricjellyfish.net> wrote:
>
>
>>>I'm writing Ruby SWIG-based bindings.
>>> http://pub.cozmixng.org/~kou/diff/svn-add-ruby-20050104.diff
>
>
>>First of all, there seem to be some parts of the diff that change things
>>that aren't specific to the ruby bindings,
>
>
> Is it swapping %include position for #include position? (See
> the attachment.)
That was one spot I noticed. Also you're changing the version of swig
we compare against in swig.m4. Has that been tested with the other
language bindings?
>> and the whole thing really
>>needs a log message indicating what it's doing so that it can be more
>>easily reviewed.
>
>
> It is for SWIG-Ruby.
>
> The codes generated by %include sometimes need some type
> declarations. We have to use #include before the codes
> generated by %include. So, I swapped %include position for
> #include position.
That seems reasonable. In general though when submitting a patch it's a
good idea to format your log message in the style used by the rest of
Subversion, see the "Writing log messages" section in the HACKING file.
In this case you might have something like:
The code generated by swig when you use %include sometimes needs type
declarations from Subversion header files. To account for this swap the
order of #include and %include.
* subversion/bindings/swig/svn_ra.i: swap order of %include and #include
* subversion/bindings/swig/core.i: ditto.
(and then similar things for the rest of the files modified)
Specific comments about what is being modified in each file makes it
much easier for developers to review a change, either before committing
it or after someone else commits it.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Ruby SWIG-based bindings
Posted by Kouhei Sutou <ko...@cozmixng.org>.
Hi,
In <41...@electricjellyfish.net>
"Re: [PATCH] Ruby SWIG-based bindings" on Tue, 04 Jan 2005 12:37:46 -0500,
Garrett Rooney <ro...@electricjellyfish.net> wrote:
> > I'm writing Ruby SWIG-based bindings.
> > http://pub.cozmixng.org/~kou/diff/svn-add-ruby-20050104.diff
> First of all, there seem to be some parts of the diff that change things
> that aren't specific to the ruby bindings,
Is it swapping %include position for #include position? (See
the attachment.)
> and the whole thing really
> needs a log message indicating what it's doing so that it can be more
> easily reviewed.
It is for SWIG-Ruby.
The codes generated by %include sometimes need some type
declarations. We have to use #include before the codes
generated by %include. So, I swapped %include position for
#include position.
> Second, the Svn::Client stuff seems a bit suboptimal to me. I don't
> really like how the Context object is being passed in manually to each
> function, it doesn't feel very object oriented. You might want to take
> a look at the way the perl bindings work, where there's a SVN::Client
> object that includes the context and automagically adds it to each
> method call. See subversion/bindings/swig/perl/native/Client.pm for
> details on how this is being done there.
Svn::Client is my next work.
Thanks for advice. It will be useful.
> All in all I think you're making good progress though, and I'd love to
> help get this committed and hopefully eventually get you access to
> maintain it directly in the tree.
Thanks.
--
kou
Re: [PATCH] Ruby SWIG-based bindings
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Kouhei Sutou wrote:
> Hi,
>
> I'm writing Ruby SWIG-based bindings.
> http://pub.cozmixng.org/~kou/diff/svn-add-ruby-20050104.diff
>
> This is not complete yet. But some examples work:
>
> * tools/examples/svnshell.rb: Ruby version of
> tools/examples/svnshell.py.
>
> * tools/examples/svnlook.rb: Ruby version of
> tools/examples/svnlook.py.
>
>
> I want to administrate my codes by version control system.
> I'm afraid of loosing my codes by human error.
> Could you let me use http://svn.collab.net/repos/ to do?
This stuff looks fantastic, and I'd love to see it committed. A few
minor comments though.
First of all, there seem to be some parts of the diff that change things
that aren't specific to the ruby bindings, and the whole thing really
needs a log message indicating what it's doing so that it can be more
easily reviewed. It may be easier to do that if you break it up into
multiple smaller patches.
Second, the Svn::Client stuff seems a bit suboptimal to me. I don't
really like how the Context object is being passed in manually to each
function, it doesn't feel very object oriented. You might want to take
a look at the way the perl bindings work, where there's a SVN::Client
object that includes the context and automagically adds it to each
method call. See subversion/bindings/swig/perl/native/Client.pm for
details on how this is being done there.
All in all I think you're making good progress though, and I'd love to
help get this committed and hopefully eventually get you access to
maintain it directly in the tree.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Ruby SWIG-based bindings
Posted by Philip Martin <ph...@codematters.co.uk>.
Justin Erenkrantz <ju...@erenkrantz.com> writes:
> Now that 1.3.24 is out, we should investigate whether we want to bump
> everyone up to that: but, as we understand it, it's not practical to
> support 1.3.19-1.3.21 and 1.3.24 at the same time. So, that really
> places me in the camp that we should hold off a bit on 1.3.24 to see
> if the SWIG folks change their mind yet again on how things should
> work... *sigh* -- justin
The last time this was discussed one of the swig developers said they
were now making more effort to preserve the ABI.
http://svn.haxx.se/dev/archive-2004-12/0730.shtml
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Ruby SWIG-based bindings
Posted by Max Bowsher <ma...@ukf.net>.
John Lenz wrote:
> On 01/11/05 11:48:29, Greg Hudson wrote:
>>
>> (2) Practically speaking, our situation with swig 1.3.24 will be much
>> better than it is with 1.3.21 because there is no runtime library to
>> depend on. Even if swig 1.3.25 changes everything, we won't have to
>> require that people have swig 1.3.24 *installed*, only that they have to
>> drop it into the build tree in order to build. And we can ship it as
>> part of our tarfile, of course.
>>
>
> Exactly. If no one else tries, I will try and figure out and get those
> patches working sometime next week. I am just going to concentrate on the
> 1.x line, because I can't get the latest svn code working (what I assume
> is
> the 2.0 branch).
What you are saying is a but confusing.
The 1.x line *IS* the latest code, i.e. trunk.
If, by 1.x line, you actually mean the 1.1.x branch, then I should point out
that new features *never* go into patch releases, so your patch would be
unusable until it was ported to trunk anyway.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Ruby SWIG-based bindings
Posted by John Lenz <le...@cs.wisc.edu>.
On 01/11/05 11:48:29, Greg Hudson wrote:
>
> (2) Practically speaking, our situation with swig 1.3.24 will be much
> better than it is with 1.3.21 because there is no runtime library to
> depend on. Even if swig 1.3.25 changes everything, we won't have to
> require that people have swig 1.3.24 *installed*, only that they have to
> drop it into the build tree in order to build. And we can ship it as
> part of our tarfile, of course.
>
Exactly. If no one else tries, I will try and figure out and get those
patches working sometime next week. I am just going to concentrate on the
1.x line, because I can't get the latest svn code working (what I assume is
the 2.0 branch).
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Ruby SWIG-based bindings
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2005-01-10 at 18:37, Justin Erenkrantz wrote:
> Now that 1.3.24 is out, we should investigate whether we want to bump
> everyone up to that: but, as we understand it, it's not practical to
> support 1.3.19-1.3.21 and 1.3.24 at the same time. So, that really places
> me in the camp that we should hold off a bit on 1.3.24 to see if the SWIG
> folks change their mind yet again on how things should work... *sigh* --
> justin
I think you're making two errors here:
(1) Although it's not explicit, I think you're making a moral judgement
against swig here, without understanding that their 1.3.x line is like
our 0.x line--no compatibility guarantees whatsoever. It was our
decision to build our release on quicksand.
(2) Practically speaking, our situation with swig 1.3.24 will be much
better than it is with 1.3.21 because there is no runtime library to
depend on. Even if swig 1.3.25 changes everything, we won't have to
require that people have swig 1.3.24 *installed*, only that they have to
drop it into the build tree in order to build. And we can ship it as
part of our tarfile, of course.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Ruby SWIG-based bindings
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, January 10, 2005 3:30 PM +0000 Max Bowsher <ma...@ukf.net>
wrote:
> That's a little difficult, since the perl/python bindings currently
> require 1.3.19 to 1.3.21, no later or earlier.
>
> It would be OK to have configure make seperate decisions on whether the
> swig version was suitable for each language, though.
As John mentioned, that's not practical as it stands right now because they
changed how SWIG interacts with the rest of the system. So, no SWIG
release greater than 1.3.21 will work at all for anything without changes
throughout the build system.
Now that 1.3.24 is out, we should investigate whether we want to bump
everyone up to that: but, as we understand it, it's not practical to
support 1.3.19-1.3.21 and 1.3.24 at the same time. So, that really places
me in the camp that we should hold off a bit on 1.3.24 to see if the SWIG
folks change their mind yet again on how things should work... *sigh* --
justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Ruby SWIG-based bindings
Posted by John Lenz <le...@cs.wisc.edu>.
On 01/10/05 09:46:59, John Peacock wrote:
> Max Bowsher wrote:
>
>> Kouhei Sutou wrote:
>>
>>> I want to require SWIG 1.3.22 or later.
>>> Because Ruby module of SWIG 1.3.21 has a bug. It's a %import
>>> handling(*).
>>
>>
>> That's a little difficult, since the perl/python bindings currently
>> require 1.3.19 to 1.3.21, no later or earlier.
>
> And the additional difficulty that SWIG 1.3.22 changed the build process
> such that the runtime libraries are no longer available (i.e. the targets
> don't exist in the SWIG Makefile). Any project intending to use SWIG
> runtime libraries must build them manually.
Wrong, there are no more runtime libraries. Gone.
> Subversion has not added
> code to do that; there was a discussion with one of the SWIG developers
> to change how Subversion worked wrt SWIG, but I believe that was shot
> down because it would orphan all existing installations.
Well, the reason I stopped is because I don't know enough about the
internal build process of subversion to get SWIG working to the
satisfaction of the devs, but at least from the SWIG side of the fence the
patches I posted work fine. I was getting a bunch of errors about
mixmatched subversion versions and whatnot. Someone with a little more
knowledge subversion needs to step up to the plate, and I am willing to
help them. Or when I get around to it I will probably try and learn more.
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Ruby SWIG-based bindings
Posted by John Peacock <jp...@rowman.com>.
Max Bowsher wrote:
> Kouhei Sutou wrote:
>
>> I want to require SWIG 1.3.22 or later.
>> Because Ruby module of SWIG 1.3.21 has a bug. It's a %import
>> handling(*).
>
>
> That's a little difficult, since the perl/python bindings currently
> require 1.3.19 to 1.3.21, no later or earlier.
And the additional difficulty that SWIG 1.3.22 changed the build process
such that the runtime libraries are no longer available (i.e. the
targets don't exist in the SWIG Makefile). Any project intending to use
SWIG runtime libraries must build them manually. Subversion has not
added code to do that; there was a discussion with one of the SWIG
developers to change how Subversion worked wrt SWIG, but I believe that
was shot down because it would orphan all existing installations.
You should probably check the archives here:
http://svn.haxx.se/dev/
for the gory details...
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Ruby SWIG-based bindings
Posted by Max Bowsher <ma...@ukf.net>.
Kouhei Sutou wrote:
> I want to require SWIG 1.3.22 or later.
> Because Ruby module of SWIG 1.3.21 has a bug. It's a %import
> handling(*).
That's a little difficult, since the perl/python bindings currently require
1.3.19 to 1.3.21, no later or earlier.
It would be OK to have configure make seperate decisions on whether the swig
version was suitable for each language, though.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Ruby SWIG-based bindings
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Kouhei Sutou wrote:
> Hi,
>
> Thanks for playing.
>
> In <41...@electricjellyfish.net>
> "Re: [PATCH] Ruby SWIG-based bindings" on Sat, 08 Jan 2005 11:52:54
-0500,
> Garrett Rooney <ro...@electricjellyfish.net> wrote:
>
>
>> It appears that the -prefix option for the SWIG Ruby support is
fairly recent. It doesn't work in version 1.3.21 anyway, which is what
my linux distribution ships. It looks like the Perl bindings work
around the lack of this kind of support by manually introducing %module
names in the appropriate .i files. You might want to look at doing the
same thing.
>
>
>
> I want to require SWIG 1.3.22 or later.
> Because Ruby module of SWIG 1.3.21 has a bug. It's a %import
> handling(*).
Ok, that seems reasonable, but if that's the case then the ruby bindings
should be deactivated in configure if an older version of swig is found.
I'll try again once I've had time to install a newer version of swig.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Ruby SWIG-based bindings
Posted by Kouhei Sutou <ko...@cozmixng.org>.
Hi,
Thanks for playing.
In <41...@electricjellyfish.net>
"Re: [PATCH] Ruby SWIG-based bindings" on Sat, 08 Jan 2005 11:52:54 -0500,
Garrett Rooney <ro...@electricjellyfish.net> wrote:
> It appears that the -prefix option for the SWIG Ruby support is fairly
> recent. It doesn't work in version 1.3.21 anyway, which is what my
> linux distribution ships. It looks like the Perl bindings work around
> the lack of this kind of support by manually introducing %module names
> in the appropriate .i files. You might want to look at doing the same
> thing.
I want to require SWIG 1.3.22 or later.
Because Ruby module of SWIG 1.3.21 has a bug. It's a %import
handling(*).
--
(*) http://mailman.cs.uchicago.edu/pipermail/swig/2004-April/009504.html
> Also, the run-tests.sh script is misspelling LD_LIBRARY_PATH, and
> hardcoding LD_LIBRARY_PATH is bad anyway, the variable is named
> different things on different systems (Mac OS X specifically comes to
> mind), so you should probably use apr-config's --shlib-path-var option
> to figure out the right variable.
OK.
But I realized that we don't need to change LD_LIBRARY_PATH
and so on. We are using -rpath.
> I'm also having a bunch of trouble running the tests... I have to
> hardcode the relative path to util.rb instead of just doing a require
> "util" in the various places it's used, no clue why that's needed.
You need to run test/test_*.rb via test/run-test.rb (its old
name is test/runner.rb). The script configures $LOADPATH of
ruby before running test.
--
kou
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Ruby SWIG-based bindings
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Some more thoughts now that I've actually had time to download this
stuff and play around with it (actually I used the more recent diff in
that directory, not the one that was posted).
It appears that the -prefix option for the SWIG Ruby support is fairly
recent. It doesn't work in version 1.3.21 anyway, which is what my
linux distribution ships. It looks like the Perl bindings work around
the lack of this kind of support by manually introducing %module names
in the appropriate .i files. You might want to look at doing the same
thing.
Also, the run-tests.sh script is misspelling LD_LIBRARY_PATH, and
hardcoding LD_LIBRARY_PATH is bad anyway, the variable is named
different things on different systems (Mac OS X specifically comes to
mind), so you should probably use apr-config's --shlib-path-var option
to figure out the right variable.
I'm also having a bunch of trouble running the tests... I have to
hardcode the relative path to util.rb instead of just doing a require
"util" in the various places it's used, no clue why that's needed.
Anyway, I still haven't gotten the tests to actually run, but I can get
little toy apps to run (i.e. creating a pool, or something else trivial
like that), but when I try to require more complex parts of the system,
like svn/client I get errors because it can't pull in svn/ext/delta for
some reason. Manually pulling in svn/core, svn/delta, then svn/client
seems to work around the problem, but I still haven't managed to make it
do anything especially useful yet.
Anyway, just figured you'd like to hear about the problems and solutions
I've run across so far.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org