Re: svn commit: r932796 - /subversion/trunk/subversion/libsvn_wc/wc_db.h

[Greg Stein <gs...@gmail.com>]

On Sat, Apr 10, 2010 at 18:08,  <st...@apache.org> 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?

Cheers,
-g

Re: svn commit: r932796 - /subversion/trunk/subversion/libsvn_wc/wc_db.h

[Stefan Sperling <st...@elego.de>]

On Sat, Apr 10, 2010 at 08:41:31PM -0400, Greg Stein wrote:
> On Sat, Apr 10, 2010 at 18:08,  <st...@apache.org> 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