Re: API issues we might want to solve for 1.0

On Fri, Dec 12, 2003 at 11:02:08AM -0500, Greg Hudson wrote:
> #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.

I believe that the svn_client interface is also prone to ABI changes,

The following booleans are available as options to svn_client functions:
  force, recurse, ignore ancestry, dry run, no diff deleted, strict node
  history, discover changed paths, descend, get_all, update, no_ignore,
  nonrecursive.

Some or all of these may become relevant to functions that they are
not currently supported with. Also, some new boolean options may become
relevant to some or all of the existing interface functions.

I think it will be a significant but worthwhile effort to feature-proof
these interfaces (and the command-line/configuration system).

http://www.contactor.se/~dast/svn/archive-2003-07/0197.shtml

This is probably too much to accomplish before 1.0, though.

> #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.

This is my fault. I've been promising to work on this for a long time.
I've started on it several times, but haven't had the resolve to see it
through to completion.

However, I can much more easily (and readily) produce a getdate.y
replacement that recognizes a more managable set of date formats, one
that could be extended in the future to support localization.

If we are willing to abandon the localization support, I can produce
a new, simplified date parser before the end of the year.

--ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 12 18:47:32 2003