David James requested that I narrow my project proposal down to working
on the callback patch and the Client, Working Copy, and Delta libraries.
That seems more than reasonable to me; the modified application is
pasted in full below for anyone on this list who can't get at it via
Google's Summer of Code page. As always, comments and suggestions are
more than welcome.
Aside from the obvious, the primary changes include the removal of the
various 'weasel clauses' in the area of thorough tests; with this much
less territory to cover, a solid test harness should be much less
challenging to put in place.
[I'm not sure Thunderbird's "Paste as Quotation" function is going to
wrap this text before it is sent, so please forgive me if that turns out
to be the case.]
-Walter
> Update Notes:
> Per your request, I've narrowed the project proposal to the Client, Delta, and Working Copy libraries. This has allowed me to significantly upgrade the time allocated to each. If all goes well with the development, this additional time will allow for a general increase in test coverage, since that was the area suffering most due to the time crunch involved in attempting to cover the entire API in two months.
>
> Description from http://subversion.tigris.org/project_tasks.html:
> The Subversion Python bindings are currently incomplete in the functionality that they expose (for one example see the above issue). Furthermore, the Python bindings are currently extremely unpythonic in their structure, and could do with a layer of python code to make them so. The bindings should first be brought up to date and all functionalities completely implemented, and second be wrapped in a set of Python classes implementing an interface more friendly to python developers.
>
> General Design:
>
> The design will, in general, follow that of the Ruby bindings: add a thin layer of Python code on top of the generated Swig bindings to provide more 'Pythonic' features and behaviors to the library. Wherever a Python-native data type is a logical fit, attempt to allow and encourage its use. The bindings should at least be compatible with Python 2.3 and up; 2.4-specific constructs are to be avoided. If there is sufficient demand, Python 2.2 compatibility might be targeted.
>
> Notes:
> * All patches adding new Python APIs are to include thorough
> Python docstrings as documentation, plus some separate
> overview/introductory material where the mentor(s) deem it
> appropriate.
> * Patches are also to include test client code; this code should
> exercise the majority of the Python interface.
>
> Deliverables, in approximate order of implementation:
> * Patch to work around inability to set baton/callback pairs in
> Python. This may be a bit messy, but the idea is to wrap all
> uses of the SWIG-level Python interface when coding up the
> pure-Python usability-enhancement layer.
> * Patches to add a object-oriented Python API for these
> Subversion component libraries, in approximately this order,
> plus whatever functionality in 'Core' is needed at each level:
> * Client
> * Working copy, delta
> * Developer documentation providing overviews of the most common
> use cases for the libraries covered, at a higher level than
> would be appropriate for inline docstrings.
>
> Estimated Time Requirements: (note: still rough)
> * Baton/Callback patch: 8 hours
> * Client: 120 hours
> * Delta: 60 hours
> * Working Copy: 60 hours
>
> Estimated Schedule:
> * May 23: Baton/Callback patch
> * May 24-Jun 21: Client
> * Jun 14-28: Delta
> * Jun 29-Jul 13: Working Copy
> * Jul 14-Aug 21: Developer documentation, refinement, performance analysis/optimization, test coverage check, bugfixes as needed
>
> Interest/Motivation:
>
> As a user of both Python and Subversion, I very much like the idea of being able to easily interface with Subversion from one of my languages of choice. While I've not personally written Python binding libraries before, I've examinied and understood a few examples, and I know both C and Python well enough to have a good grasp of what is going on between the two.
>
> General Background/Bio:
>
> I am a computer science student at the University of Central Florida, and I recently competed in the finals for the ACM International Collegiate Programming Competition. I'm currently also working for a defense contractor, writing Java and the occasional Python/misc. code. I also have work experience in C/C++ and Perl, and knowledge Unix shell scripting and a smattering of other languages/tools.
>
> Post-SoC Intent:
>
> If I am selected to do this work for the Summer Of Code, I also intend to commit, at a minimum, to maintaining the results for a least 6-8 months after the Summer ends, and longer if it seems necessary to make the end result usable and maintainable. I may further decide to continue active development or to even expand my interest in Subversion development if we enjoy working together enough.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 12 03:29:06 2006