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

Re: svn commit: rev 4712 - in trunk/subversion: include libsvn_client clients/cmdline svnversion

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2003-02-03 14:46:42 CET

Tim Kemp wrote:

>Grrrrrr, how many more times are you going to change this interface. If
>you aren't sure of the design yet, please use a branch so that us people
>who are using the SVN libraries don't have to redo our code twice a day.
>
>This is the fourth time this parameter has caused changes in as many
>days.
>

i think karl's summed this up nicely, but i'll just note that i've got
at least one more API change coming up (moving the log message
callback/baton into the context, so that all client provided callbacks
are centralized there), and possibly one semantics changing change
(requiring config options to be passed in by the client app as part of
the context, rather than having the svn libs read them whenever they
need them).

and as for the rapid churn of changes in trunk, i'm trying to get the
pain over with as quickly as possible so that it happens now, when a
relatively small number of people have built client applications, rather
than later, when more have. i just sort of assumed that client apps
would be tracking release versions of svn rather than the dev version.
if you want to track the dev version, that's fine with me, but the API
will change, perhaps rapidly, until we've got it right.

personally, i'd rather have rapid change happening in trunk where people
are watching and commenting, than me doing this off on a branch, making
one mega-huge merge, and then finding out people have a problem with
it. not to mention the fact that as the change gets larger, there's
more chance i'll accidentally introduce a bug, and more chance that it
won't get caught. our test suite is good, but it isn't perfect, not by
a long shot, and having people watch the changes as they happen and
point out bugs is invaluable.

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 3 14:47:50 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.