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

Re: WC work, next round

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Sat, 06 Sep 2008 12:38:25 -0400

"Greg Stein" <gstein_at_gmail.com> writes:
> I think that the API that I sketched out for recording data
> (libsvn_wc/wc_db.h) is kind of at diminishing returns. I could sit
> around and continue to apply brainpower, but it feels pretty
> reasonable right now. At least far enough that I need to start some
> coding.
> So. To validate whether the API is about right, I need to write some
> code that *uses* the API. In order to that, I'm going to create a
> branch and start writing some various little bits of code. Mostly,
> I'll just be checking whether it compiles, rather than "does it work".
> Since "working" means I have to *implement* the API, which I won't do
> until some level of validation has occurred. The API client code will
> be checked in [to the branch], so that I can get feedback on how the
> API works and how it impacts the clients and how clients are intended
> to use it.
> There will probably be some changes to the API, and I might even start
> implementing some of the basics to the API. That will occur in trunk,
> and I'll merge that over to the branch. The "delta" represented by the
> branch will only be my exploration code, which is not destined to be
> delivered anywhere.
> Well. Maybe. Some of it might get folded over into some API testing
> code. Have to wait and see.
> Thoughts?

Sounds good to me. Ordinarily, I'd offer some cautionary words about
how you should make sure that any permanent code ends up on trunk sooner
rather than later... But I know I'd be preaching to the choir :-).

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-06 18:38:39 CEST

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.