You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Justin Erenkrantz <je...@apache.org> on 2002/08/11 17:49:28 UTC
Entries caching?
Well, we seem to be coming back to this in other threads.
What would we like to do about entries caching?
- Fix libsvn_wc in one swoop to correctly pass the admin_baton
everywhere.
Status: Posted an incomplete broken patch that starts the
conversion process.
Pro: Everything gets fixed.
Con: I don't have the time to complete this, so this would have to
fall to someone else.
- Branch off and commit the broken patch.
Pro: If someone steps up, they can pick up the pieces.
Con: Unlikely to work and I can't see the branch through anyway,
so the branch is likely to get out-of-date quickly.
- Add a caching-only API
Status: Patches posted (if what I posted before doesn't cleanly
apply, it'd be fairly easy to make it clean again).
Pro: Allows us to incrementally address the API concerns without
forcing to change the entirety of libsvn_wc.
Con: Philip has stated he is very much against this. I believe he
may have even vetoed this.
I'd like to see the caching hit before 1.0, but since I have a life
outside of SVN, I just can not devote the time to change all of
libsvn_wc. Everytime I try to put aside time to it, I just cry when
I look at it. In the limited time I have, I'd like to address more
attainable goals (such as getting svn-config to work properly when
we have in-tree dependencies).
Thoughts? -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Entries caching?
Posted by mark benedetto king <bk...@inquira.com>.
On Sun, Aug 11, 2002 at 10:49:28AM -0700, Justin Erenkrantz wrote:
> - Add a caching-only API
> Status: Patches posted (if what I posted before doesn't cleanly
> apply, it'd be fairly easy to make it clean again).
> Pro: Allows us to incrementally address the API concerns without
> forcing to change the entirety of libsvn_wc.
> Con: Philip has stated he is very much against this. I believe he
> may have even vetoed this.
>
It would certainly be nice to be able to enjoy the benefits of entries
caching now, allowing the libsvn_wc rework to be scheduled for post-1.0,
rather than be stuck with a slow WC implementation.
First impressions of a product are hard to change, and while people
will overlook problems with an "alpha" product, they're likely to
judge 1.0 a bit more harshly.
I can see the benchmark comparison charts in my mind's eye already.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Entries caching?
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Justin Erenkrantz <je...@apache.org> writes:
> What would we like to do about entries caching?
>
> - Fix libsvn_wc in one swoop to correctly pass the admin_baton
> everywhere.
> Status: Posted an incomplete broken patch that starts the
> conversion process.
> Pro: Everything gets fixed.
> Con: I don't have the time to complete this, so this would have to
> fall to someone else.
I think #1, and no prob if you don't have time, someone else can do
it.
> I'd like to see the caching hit before 1.0, but since I have a life
> outside of SVN, I just can not devote the time to change all of
> libsvn_wc. Everytime I try to put aside time to it, I just cry when
> I look at it. In the limited time I have, I'd like to address more
> attainable goals (such as getting svn-config to work properly when
> we have in-tree dependencies).
Oh, this *will* get done before 1.0, don't worry. Every now and then
we have a big, must-be-done-in-one-swoop task like this, and all it
means is that it gets delayed until someone gets a day or two take it
on. If you, or Philip, weren't ever going to get that day, that's
okay -- Mike or Ben or I will allocate time for it. We've just been
working on other stuff lately, while hoping that maybe serendipity
would strike and we'd see the Big Commit from Philip or you, that's
all.
And [reading ahead in my mail] it looks like Philip has a patch almost
ready to go, so the Serendipity Strategy wins again :-).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Entries caching?
Posted by Philip Martin <ph...@codematters.co.uk>.
Justin Erenkrantz <je...@apache.org> writes:
> Well, we seem to be coming back to this in other threads.
>
> What would we like to do about entries caching?
>
> - Fix libsvn_wc in one swoop to correctly pass the admin_baton
> everywhere.
> Status: Posted an incomplete broken patch that starts the
> conversion process.
> Pro: Everything gets fixed.
> Con: I don't have the time to complete this, so this would have to
> fall to someone else.
>
> - Branch off and commit the broken patch.
> Pro: If someone steps up, they can pick up the pieces.
> Con: Unlikely to work and I can't see the branch through anyway,
> so the branch is likely to get out-of-date quickly.
>
> - Add a caching-only API
> Status: Patches posted (if what I posted before doesn't cleanly
> apply, it'd be fairly easy to make it clean again).
> Pro: Allows us to incrementally address the API concerns without
> forcing to change the entirety of libsvn_wc.
> Con: Philip has stated he is very much against this. I believe he
> may have even vetoed this.
>
> I'd like to see the caching hit before 1.0, but since I have a life
> outside of SVN, I just can not devote the time to change all of
> libsvn_wc. Everytime I try to put aside time to it, I just cry when
> I look at it. In the limited time I have, I'd like to address more
> attainable goals (such as getting svn-config to work properly when
> we have in-tree dependencies).
>
> Thoughts? -- justin
I have another patch for 749; it passes the access baton to
svn_wc__entry_modify. It touches quite a lot of functions as you can
imagine :-) It passes the regression tests, and has done so for a few
days now, but other things keep breaking. The issue 838 patch broke
it, and to a lesser degree the recent URL keyword patch. My patch also
uncoverered some path canonicalization bugs that I have since fixed.
The patch is just about ready to go, I'm just looking at a final
revert problem (svn_wc_revert is not nice, it's nearly as bad as
svn_wc_add). It's not a case covered by the regression tests.
If you wait until this patch gets applied you may well find caching
much easier.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org