Re: add NODES.prior_deleted boolean column

2010-09-29 Thread Philip Martin
Greg Stein writes: > To do this, it seems that we're going to need to expose (from wc_db.h) > a structure containing "all" the row data. Thankfully, this big ol' > structure is *private* to libsvn_wc, and we can change it at will > (unlike svn_wc_status_t). I would suggest that we use a callback

Re: add NODES.prior_deleted boolean column

2010-09-28 Thread Greg Stein
On Tue, Sep 28, 2010 at 08:46, Philip Martin wrote: > Julian Foad writes: > >>> I believe the answer is "often". A simple 'svn status' will need to >>> distinguish between 'A' and 'R', and that is done by checking >>> prior_deleted. >>> >>> And no... this amount of denormalization will not hurt u

Re: add NODES.prior_deleted boolean column

2010-09-28 Thread Philip Martin
Julian Foad writes: >> I believe the answer is "often". A simple 'svn status' will need to >> distinguish between 'A' and 'R', and that is done by checking >> prior_deleted. >> >> And no... this amount of denormalization will not hurt us. > > OK. I know that "svn status" speed is a big deal. I

Re: add NODES.prior_deleted boolean column

2010-09-23 Thread Greg Stein
On Thu, Sep 23, 2010 at 13:32, Julian Foad wrote: >... >> > 'excluded': >> > >> > I think we need to support 'excluded' at op_depth > 0 on a copied-here >> > node (only for a child, not the root of the copy), and also on a >> > moved-here node (child).  We should distinguish these.  How? >> >> "sh

Re: add NODES.prior_deleted boolean column

2010-09-23 Thread Julian Foad
Hi Greg. Thanks for the discussion. I'm at least getting to grips with the basics of op_depth functioning. Greg Stein wrote: > On Thu, Sep 23, 2010 at 09:19, Julian Foad wrote: > > On Wed, 2010-09-22, Greg Stein wrote: > >... > >> > That flag would just mean "There is a row for the same path wi

Re: add NODES.prior_deleted boolean column

2010-09-23 Thread Greg Stein
On Thu, Sep 23, 2010 at 09:19, Julian Foad wrote: > On Wed, 2010-09-22, Greg Stein wrote: >... >> > That flag would just mean "There is a row for the same path with a >> > smaller op_depth and with a non-negative kind of presence", right?  So >> > whether we actually store that flag is a matter of

Re: add NODES.prior_deleted boolean column

2010-09-23 Thread Julian Foad
On Wed, 2010-09-22, Greg Stein wrote: > On Tue, Sep 21, 2010 at 13:41, Julian Foad wrote: > > Greg Stein wrote: > >> After working through the several email messages, and discussion, I > >> believe we're now down to a simple change: > >> > >> * add a "prior_deleted" flag to NODES > >> > >> The flag

Re: add NODES.prior_deleted boolean column

2010-09-22 Thread Greg Stein
On Wed, Sep 22, 2010 at 18:27, Greg Stein wrote: >... > The children don't have to be touched. They just hang out in their > deleted state with the same op_depth. We *never* want to modify a rows > op_depth. That is part of its primary key(!). Let me clarify this. There is one situation where we

Re: add NODES.prior_deleted boolean column

2010-09-22 Thread Greg Stein
On Tue, Sep 21, 2010 at 13:41, Julian Foad wrote: > Greg Stein wrote: >> After working through the several email messages, and discussion, I >> believe we're now down to a simple change: >> >> * add a "prior_deleted" flag to NODES >> >> The flag simply means that a node exists prior to this layer

Re: add NODES.prior_deleted boolean column

2010-09-21 Thread Julian Foad
Pish, only the OpenOffice attachment was preserved. Here's a PDF copy, temporarily: . - Julian On Tue, 2010-09-21 at 18:41 +0100, Julian Foad wrote: > Greg Stein wrote: > > After working through the several email messages, and discussion, I > > belie

Re: add NODES.prior_deleted boolean column

2010-09-21 Thread Julian Foad
Greg Stein wrote: > After working through the several email messages, and discussion, I > believe we're now down to a simple change: > > * add a "prior_deleted" flag to NODES > > The flag simply means that a node exists prior to this layer and has > been deleted or moved-away. The 'presence' colu