On Wed, Jul 10, 2002 at 03:05:39AM -0700, Justin Erenkrantz wrote:
> Thoughts? It's obvious people have thought about this before
> and gave up. So, before I start down this road, I'd like to
> get feedback from those who tried before. =) -- justin
>
MOHIAM: Many men have tried.
PAUL: They tried and failed?
MOHIAM: They tried and died.
I spent a little over half a day looking at making libsvn_wc interally
baton driven without changing the exposed API. It quickly blossomed
into a huge effort. Had it only been a lot of simple changes, I might
have persevered, but there are some fine points that scared me off:
1.) There are really two views of the entries: one with deleted entries
shown and one with them ignored. It's not impossible to effect this with
an in-memory cache, but it means that rework needs to be especially careful,
because it needs to keep track of which view the code is interested in.
This probably also means that a "delete" of an entry needs to remove it from
the "ignore deleted" view immediately, but not from the other view until
later. I didn't look closely at this, but it worried me.
2.) The library consumes its own API. While there's nothing wrong with
this, it does mean that nearly all of the exported functions would have
needed baton-ized versions. Take a look. There are a whole bunch of
exported functions.
My feeling is that libsvn_wc needs to be split into two layers: one that
is baton-only, and another that consumes that one's API. This should
resolve (2), and make it easier to focus on (1). This will be a big
effort, but the payoffs could be huge. I measured, IIRC, over 90% of
client-side processing spent in manipulating the entries files.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 10 15:01:05 2002