[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: API issues we might want to solve for 1.0

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2003-12-12 21:47:06 CET

On Fri, 2003-12-12 at 14:10, kfogel@collab.net wrote:
> > #1: We define symbols in the APR namespace:

> I suggest we simply switch the prefixes (prefices?) to "svn_apr_" and
> "SVN_APR_", to avoid any possibility of conflict, then remove our
> definitions and switch them back when and if APR gets these functions.

Except that removing function is an API change.

If we're pretty sure these will get into APR, we could name them
svn__apr_foo and SVN__APR_FOO, make sure there are no doxygen comments
for them, and note in the header files that they're for internal use
only. Then it should be reasonably safe to remove them from the
libraries in the future.

If we think some of them won't make it into APR, then we should pick
names we're comfortable with supporting.

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

> The API change itself is no more difficult later than it is now. We
> will break code & binary compatibility, but we've always accepted that
> future versions will do that, and we have a release numbering scheme
> to handle it.

I think we will find (either the hard way or the easy way) that after
1.0, API changes have to be batched up and made at rare intervals--like,
every five years or so. We'll need to develop ways for people to have
old and new versions of Subversion installed on the same system, and
we'll have to write special documentation to help people transition to
the new API. So, if we want to support new features without a lot of
pain, we either have to do it without breaking backward compatibility
(i.e. adding new functions, but preserving old ones) or we have to
anticipate them now.

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

> (I don't see why it would be worth it now, but not worth it after
> 1.0.)

Because after 1.0, we have to worry about application code which calls
svn_wc_get_actual_target() and expects to see NULL in *target for
directories, or application code which calls the various APIs which
support NULL path elements and passes NULL.

> > #5: svn_ra_init_ra_libs and friends use a void * baton instead of an
> > opaque type.

> Sure. Not a tragedy if it doesn't get fixed before 1.0; I'm of a mind
> to punt on the 1.0 release line, but maybe get a fix into trunk when
> sometime when we're going to break binary compatibility anyway.

> Oh wait, this wouldn't even break binary compatibility, would it?

It would break source compatibility, but not binary compatibility.

> > #6: We still use getdate.y, which implements a bizarre and arbitrary
> > set of date formats. (Did you know that "3" is a date?)

> We don't really need to fix this for 1.0, as long as whatever date
> formats we extend to in the future are a superset of what we currently
> support. (Or a superset of all the ones people actually use, anyway
> :-) ).
> What are the particular foibles people are relying on already?

I get the impression that people rely on things like "yesterday." I'm
okay with that particular one, but there are some particularly weird
things like "6/30 1440" for 2:40pm on June 30. Or "4 days ago 3" for
3am four days ago.

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.