David James <james82@gmail.com> writes:
> Questions:
> - Is it OK to create the new libsvn_cmdline library? It will make my
> command-line SWIG work this summer much easier.
Personally, I would like to see some of the abstraction patches first.
Those patches can include the new libsvn_cmdline/ subdir if necessary.
Then, assuming the patches are okay to check in on the mainline, we
can do so.
We (the project) need to do this in such a way that any changes
committed are still good even if you were to drop of the face of the
earth at any random moment. That's a general principle: even if
change X is checked in for the explicit purpose of facilitating change
Y down the road, change X still has to stand on its own merits,
because there's no guarantee that Y will ever happen. Y may be very
*likely* to happen -- as I think it is in this case -- but by
following the general principle, we can never go wrong :-).
Are you positive you need libsvn_cmdline? It seems plausible to me,
but maybe it would make more sense to start on the client, and then
see what you need as you go? However you want to do it is fine.
If we get to the point where no patch has been committed yet, but
you're having trouble managing your changes locally, I'm +1 on
creating a branch (or branches) for this.
> - Is it possible to mark the libsvn_cmdline_cl.h API as experimental
> and subject to change? I think that the API for the command-line
> client could go through quite a few changes and improvements this
> summer and I don't want to have to worry about revving the API yet.
I think that's fine -- see if there's an standard Doxygen way to do
it, though.
> - Is it OK to use malloc / free in the SWIG bindings? In some cases,
> this seems to be the only solution because APR pools are not always
> available in a typemap.
Isn't the solution to change the typemap? Are we using malloc/free in
other bindings?
> ----------------------------------------------------------------------
> Implementation Plan
> ----------------------------------------------------------------------
>
> 1. Write a simple script which creates a Python command-line parser
> based on the svn_cl__options and svn_cl__cmd_table structures from
> main.c in subversion/clients/cmdline. The Python standard optparse
> module will do most of the work, but we will also need to write
> custom code to parse Subversion revision numbers and ranges.
Does Subversion have these effectively abstracted already? Can that
just be librarized? Much, much better to avoid code duplication,
especially if other binding languages later want to do the same thing
you're doing for Python.
> 2. Upgrade our script to dispatch each command to the appropriate
> command-line client function. This initial prototype will provide
> the full functionality of the Subversion client, but will only test
> the surface functionality of SWIG.
>
> 3. Upgrade the Subversion automated test suite to test our new script
> using the command-line test suite. Fix any errors that are found.
>
> 4. Replace each command-line C function in the Python command-line
> client with an appropriate Python implementation. Each function
> should be implemented, tested, and committed as a separate patch. If
> adding a new function reveals a bug in the underlying SWIG/Python
> library, these bugs should be reported to the Subversion development
> list.
Okay, I see how this code duplication (item 4) is necessary to achieve
the goal of getting the public APIs tested.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 29 05:54:32 2005