On Sat, Apr 10, 2010 at 08:41:31PM -0400, Greg Stein wrote: > On Sat, Apr 10, 2010 at 18:08, <[email protected]> wrote: > > Author: stsp > > Date: Sat Apr 10 22:08:37 2010 > > New Revision: 932796 > > > > URL: http://svn.apache.org/viewvc?rev=932796&view=rev > > Log: > > Add sketchy declarations of functions wrting data to the new conflict store. > > Review and comments welcome. > > Upon reflection, this approach will cause atomicity problems. The > ideal situation is to add/replace a node with all of its metadata > (including conflict data!) in one atomic transation. > > If you look at svn_wc__db_base_add_*(), they have a parameter named > CONFLICT, which can be inserted during the transaction which > adds/replaces the node data itself. > > What I would like to suggest is a "conflict builder" set of APIs that > constructs the svn_skel_t. The operation would be something like this: > > svn_skel_t *conflict = svn_wc__builder_create(result_pool); > > /* conflict == (()), representing (OPERATION) and OPERATION=() */ > > SVN_ERR(svn_wc__builder_set_update_op(conflict, base_revision, > target_revision, result_pool, scratch_pool)); > SVN_ERR(svn_wc__builder_add_text_conflict(conflict, ...)); > SVN_ERR(svn_wc__builder_add_prop_conflict(conflict, ...)); > ... > SVN_ERR(svn_wc__db_base_add_file(..., conflict, ...)); > > > I don't think we need anything fancier than an svn_skel_t for the > representation. The builder_set_*_op would just replace the OPERATION > subskel with the appropriate data. The build_add_* functions would > append new conflict subskels to the main skel. When everything is > ready, the main skel is passed into wc_db fully-formed and ready for > insertion into the database. > > Whatcha think?
I like it. Thanks, Stefan
