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

RE: svn commit: r39355 - trunk/subversion/libsvn_wc

From: Bert Huijben <rhuijben_at_sharpsvn.net>
Date: Wed, 16 Sep 2009 16:51:06 +0200

> -----Original Message-----
> From: Hyrum K. Wright [mailto:hyrum_wright_at_mail.utexas.edu]
> Sent: woensdag 16 september 2009 16:36
> To: Bert Huijben
> Cc: dev_at_subversion.tigris.org
> Subject: Re: svn commit: r39355 - trunk/subversion/libsvn_wc
> On Sep 16, 2009, at 4:11 AM, Bert Huijben wrote:
> > Author: rhuijben
> > Date: Wed Sep 16 02:11:16 2009
> > New Revision: 39355
> >
> > Log:
> > Following up on r39338, r39340, add the option of flushing the
> entries
> > cache to the remove entry and set depth database calls.
> >
> > Suggested by: gstein
> While I agree that the entries need to be flushed in these cases
> (since we are doing a write of the DB), I'm *very* leery about doing
> it conditionally. It smacks of a premature optimization, and that's
> the type of thing that we've spent *months* attempting to eliminate in
> wc-1. Plus, doing this in only one function introduces an API
> consistency across the wc_db APIs. I understand the desire to use the
> cache, and not flush it prematurely, but in this case I don't think it
> should be conditional.

Flushing always is not an option in this _temp_ function (see its name).. unless you just silently fixed all callers from svn_wc__set_depth and svn_wc__entry_remove to no longer expect an entries cache?

This temp function should be removed when we are done removing the entry write locations, but it is now a vital part of the update editor to allow removing other dependencies on the entries cache.

Other option:
Maybe the code should be moved into entries.c?

The function was designed to have just that single caller until we can remove that caller completely.


Received on 2009-09-16 16:51:23 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.