On Mon, Mar 14, 2011 at 10:53:48AM -0400, C. Michael Pilato wrote:
> > On 12.03.2011 13:47, Stefan Sperling wrote:
> >> For others who want to jump in and help, here is a list of places
> >> where the node walker is still being used. I'm not sure if we can
> >> eliminate it everywhere before release, but each of these should
> >> be looked at to see whether we can use an alternative approach to
> >> increase performance:
> >>
> >> subversion/libsvn_client/changelist.c
> >> subversion/libsvn_client/commit_util.c
> >> subversion/libsvn_client/info.c
> >> subversion/libsvn_client/merge.c
> >> subversion/libsvn_client/mergeinfo.c
> >> subversion/libsvn_client/prop_commands.c
> >> (This should be propget and propset. Proplist is already using
> >> queries involving temporary tables. Rewriting propget on top
> >> of the proplist code would be easy. Propset needs more work.)
> >> subversion/libsvn_client/ra.c
> >> subversion/libsvn_wc/update_editor.c
>
> I want to jump in and help. But (as is common for me, it seems) the first
> place I go to jump in stirs up a question. What is the motif we seek to
> apply where we need have per-path notification events that need to happen?
> For example, I'm familiar with the changelist code, so I started looking at
> making this conversion there. But we do per-path notification in that code.
> How do we approach this? Do we query old state, make the change, query new
> state, diff the states and notify on the diffs? That seems ... wrong. Is
> there any pattern established upon which I can model these changes?
The temporary table trick we're using with proplist works well if all
you're doing is reading data from the DB. It sounds like you want to make
modifications, too.
The concern seems to be that invoking a notification callback could
attempt to modify DB state, correct? Which would deadlock if you invoke
the callback after starting a transaction to tweak changelist information
but before this transaction has been committed (i.e. the write lock has
been released)?
I guess you could:
- Read all information you need to determine how the changelist needs
to be changed, using at most a handful of queries.
- Perform sanity checks using this information, and error out if you can
already determine that something won't work out for a specific path.
- Make all the changes in a transaction for all affected paths.
Try to commit the transaction.
- If the commit succeeded, notify for all paths. Else, print some error.
Would that work? We're notifying after the fact in case of success.
However, we can assume that the DB operations finish quickly, so for
the user everything will be nearly instantaneous anyway.
Received on 2011-03-14 17:06:19 CET