> -----Original Message-----
> From: Greg Stein [mailto:gstein_at_gmail.com]
> Sent: zaterdag 4 september 2010 6:28
> To: Bert Huijben
> Cc: Julian Foad; Erik Huelsmann; dev_at_subversion.apache.org
> Subject: Re: [PROPOSAL] WC-NG: merge NODE_DATA, WORKING_NODE and
> BASE_NODE into a single table (NODES)
> How confusing are you trying to make this? You're succeeding
> wonderfully.
Well, you are good at helping it more confusing for everybody.
> We are talking about *adds* and their op_depth value. What the fuck
> does that have to do with commits?
>
> All adds are very simple commit operations. They can all have the same
> op_depth value. There are no restrictions on adding more or removing
> them. They are free floating nodes within the various restructuring
> that copies/moves may have done. You can independently revert any
> single add.
>
> Get back to the original question: adds do not require variant
> op_depth values. Very simple. Any add under an added parent just uses
> that parent's op_depth.
But not making it use a specific op_depth makes adding the add harder (has
to check the parent op), the revert harder (can't just take the op_depth to
see that it can be reverted by itself) and the commit (see previous mail).
Most of this work will probably be handled by _scan_addition() and specific
DB operations like svn_wc__db_(temp_)op_copy(),
svn_wc__db_temp_op_make_copy(), etc.
I really think all of these would be easier to implement with an explicit
(non-inherited) op_depth for each add as that makes it possible to identify
the impact of these operations without scanning up all the time. (Just
looking at the op_depth would show that scanning up is not needed at all;
using the same op_depth implies that you only have to scan one specific
parent)
But maybe we should look at what Eric finds here, as he is the only one
really working on this right now. (Or it must be that I missed your commits)
The problem can be solved both ways, but for one of these two use cases this
requires more scanning upwards. (Which isn't very cheap for generic use
unless we some transaction/lock around the group of statements)
Bert
Received on 2010-09-04 11:56:25 CEST