John,
[copying the dev list so that this is archived, and others can chime in]
John Peacock wrote:
> I see that Daniel has already created a branch for the Perl bindings
> improvements. I propose that we start by going through the open issues
> for the Perl bindings and apply the following two patches:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=2632
> http://subversion.tigris.org/issues/show_bug.cgi?id=2646
I see you've committed 2646. Are you planning on closing the ticket too
(I've not poked around tigris.org yet, so I need to find out how to do that).
The patch in 2632 could use a little work. I'd remove the "I've not tested
this" comments, and the examples should probably go in to a separate
directory of example programs that use the bindings (or be used as test
scripts).
> and then review the remaining API's that are not already exported. Then
> Nik and I can split up the documentation and start backfilling. I would
> like to think this part may go fairly quickly, and we can get those
> changes ported back to trunk sooner rather than later.
The major change that I've started is the one that introduces named
parameters (and makes some of them optional if we can have sensible defaults
for them).
That can go in piece by piece -- there's no reason why every function needs
to support this all in one commit, although we probably wouldn't want to
merge the changes back to trunk until every function in a file had been
changed in that way.
This change would also introduce an external dependency on Params::Validate.
I've bought this up before, and there didn't seem to be any objection to
introducing this dependency, so I hope that will be fairly non contentious.
This touches SVN::Client. If you've got no plans in that area for the next
few days I'll prepare something on the train tomorrow.
If I really had my head I'd bring in Exception::Class as well, and use the
two of them together. See
http://jc.ngo.org.uk/blog/2007/01/15/perl-parameter-validation-and-error-handling/
for details. Exception::Class has a bigger dependency list though, and I
expect that to be too much for the userbase, at least for the moment.
> The second big task should be (IMHO) to focus on the testsuite, and see
> if we can beef up the testing to be comparable to what the Python tests
> currently cover. I view this as my opportunity to learn more about a
> foreign language where whitespace is significant... ;-)
Inline::Python :-)
Improving the test suite definitely makes sense as another task to carry out.
> The two Makefile.pl related problems are likely to require a little more
> thought:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=2479
> http://subversion.tigris.org/issues/show_bug.cgi?id=2617
>
> since ExtUtils::MakeMaker is "a maze of twisty passages, all alike" and
> will actually be harder to deal with than the bindings themselves. We
> aren't going to lose [much] by doing these last, since at worst we are
> maintaining the status quo. I have to do some heavy EU::MM hacking in
> the near future (to add support for my version.pm module), so I may be
> more able to understand what needs doing here after I dissect EU::MM for
> a while.
I'm perfectly happy to let you delve in to EU::MM.
A thought. Do we gain anything by instead switching to Module::Build? I
have no idea, since I've not used it when building and binding against
external libraries.
Other things that I'd like to investigate (the answers to some of these may
"You can already do that" -- that's fine, I just haven't investigated enough
to know that yet)
* Make sure the Perl bindings can determine their version
* Make sure that, on a per-method basis, the bindings can find out which
svn version a method was introduced (or otherwise be able to audit a
piece of code and say "This requires svn 1.4.0 as a minimum version")
* Re-implement svn(1) in Perl. As well as exercising the bindings this
should:
a) Act as a good example for anyone who wants to use the bindings, and
is wondering how to achieve a particular result.
b) Provide a test bed for people to experiment with new options and/or
functionality in the svn client -- essentially, prototyping changes
before they go in to svn.c...
N
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 17 18:40:43 2007