On Mon, Aug 18, 2008 at 7:35 AM, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> Greg Stein wrote:
>...
>> I'd much prefer to get rid of the wc1 code entirely.
>
> I think a number of us feel the same way, but while were at it, why don't we
> get rid of the clunky API[1]?
Quite possibly, yes. To be honest, I'm not sure how extensive these
changes could impact the API. I need to fully support the API
regardless, and doing that work will be very informative for what a
true wc-ng API could look like. Revamping _client to use an updated
API will further inform us.
But you can see where this is going: I don't know, don't need to know
now, and will deal with it later. :-)
I agree with the basic intent, and have made a note of it.
As I've been poring over svn_wc.h, I've been thinking that we need
svn_deprecated.h and move all of the function signatures and types
into that file. Let them all sit there, undocumented ("want doc? look
in prior releases. kthxbai."). That header would then be included by
all other headers (old code including (say) svn_wc.h still needs the
deprecated API to be visible). Doing this would clean up our header
files a LOT. Thoughts?
> We can continue to ship wc1 in parallel to
> wc-ng, but officially deprecate it and promise never to update or support
> it. If we really wanted to physically remove the wc1 code, we could
> reimplement wc1 as a thin wrapper around wc-ng. We wouldn't be breaking any
> compatibility guidelines *and* we'd get to remove API cruft.
I don't think it would proper for us to never update/support any code
we ship. Thus, wc1 would be a wrapper, which is my current intent. I
just don't know (yet) whether a wc-ng API would be radically different
from a wc1 API.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-18 17:06:39 CEST