As it's much easier to make API changes before 1.0 than after, here
are a list of issues we might want to solve soon. The first three
seem important; the rest are just unfortunate foibles (except for #6,
but that would require a serious push to fix). Many of these have
received attention in the past, but time marched on without anyone
fixing them.
#1: We define symbols in the APR namespace:
In svn_sorts.h: apr_hash_sorted_keys
apr_array_prepend
In svn_types.h: APR_ARRAY_IDX
APR_ARRAY_PUSH
apr_atoui64
IMPACT OF PROBLEM: We're not very sociable, and might conflict with
a future version of APR which includes these symbols.
DIFFICULTY OF FIX: Depends on how we fix them.
#2: The svn_client interface accepts a pointer to a context
structure which is allocated by the caller and filled in by the
caller.
IMPACT OF PROBLEM: We have no way of extending this structure with
new fields. We should provide a function to create and
initialize a context structure and mandate that the caller use
it.
DIFFICULTY OF FIX: Minor.
#3: Recursion is specified as a boolean in svn_ra operations, but
we have vague plans to support either tri-state (0/1/infinity)
recursion or arbitrary recursion depth.
IMPACT OF PROBLEM: Supporting enhanced recursion will require a
difficult API change.
DIFFICULTY OF FIX: Medium; we need to agree on a new API, and then
all ra layers need a trivial change across half a dozen
functions.
#4: Even though we introduced "" as a no-op path element years ago,
svn_wc_get_actual_target() returns NULL in *target if anchor is
the actual target, and various APIs support NULL path elements
for compatibility with that.
IMPACT OF PROBLEM: API is somewhat inconsistent and confusing.
Fixing after 1.0 is unlikely to ever be worth the effort.
DIFFICULTY OF FIX: Medium, and with some change of destabilization.
(I had a go at this in issue #999.)
#5: svn_ra_init_ra_libs and friends use a void * baton instead of an
opaque type.
IMPACT OF PROBLEM: The interface is needlessly non-type-safe.
DIFFICULT OF FIX: Minor.
#6: We still use getdate.y, which implements a bizarre and arbitrary
set of date formats. (Did you know that "3" is a date?)
IMPACT OF PROBLEM: We'll be stuck with getdate.y forever.
DIFFICULTY OF FIX: Major. And we already have people (including
developers) relying on getdate's foibles. Bleah.
#7: Overly defensive programming in:
svn_path_uri_endode
svn_path_uri_decode
svn_cstring_split_append
The path_uri functions actually document that they will pass
through NULL, even though there is no use case which makes that
especially convenient. svn_cstring_split_append accepts a NULL
input even though it is not documented that it does so.
IMPACT OF PROBLEM: Minor; we will be trapped into providing
interface guarantees for these functions which we don't provide
most places.
DIFFICULTY OF FIX: Trivial.
#8: log_message_receiver_t accepts a hash of changed paths instead
of an array. This appears to be for the convenience of existing
callers.
IMPACT OF PROBLEM: Minor; changed_paths is not a pointer to const
since you can't iterate over a const hash table.
DIFFICULTY OF FIX: Medium.
#9: log_message_receiver_t and commit_callback_t pass dates as const
char * instead of apr_time_t, as a nod to the fact that dates
are stored as text properties on revisions.
IMPACT OF PROBLEM: API is not as clean as it could be; users of
those types must perform extra input validation because of the
possibility of malformed date strings.
DIFFICULTY OF FIX: Medium.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 12 17:06:02 2003