[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: atomic update

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Tue, 30 Mar 2010 11:17:41 +0100

Greg Stein <gstein_at_gmail.com> writes:

> On Mon, Mar 29, 2010 at 19:40, <gstein_at_apache.org> wrote:
>>...
>> +++ subversion/trunk/subversion/libsvn_wc/wc_db.h Mon Mar 29 23:40:55 2010
>>...
>> +/* ### docco
>> +
>> +   Perform an "update" operation at this node. It will create/modify a BASE
>> +   node, and possibly update the ACTUAL tree's node (e.g put the node into
>> +   a conflicted state).
>> +
>> +   ### there may be cases where we need to tweak an existing WORKING node
>> +
>> +   ### this operations on a single node, but may affect children
>> +
>> +   ### the repository cannot be changed with this function, but a "switch"
>> +   ### (aka changing repos_relpath) is possible
>> +
>> +   ### one of NEW_CHILDREN, NEW_CHECKSUM, or NEW_TARGET must be provided.
>> +   ### the other two values must be NULL.
>> +   ### should this be broken out into an update_(directory|file|symlink) ?
>> +
>> +   ### how does this differ from base_add_*? just the CONFLICT param.
>> +   ### the WORK_ITEMS param is new here, but the base_add_* functions
>> +   ### should probably grow that. should we instead just (re)use base_add
>> +   ### rather than grow a new function?

What is NEW_TARGET?

I guess NEW_CHILDREN is supposed to allow a directory to be added
without being incomplete. How is that going to work? The skeleton
implementation of base_add_directory adds an incomplete node for each
child, files as well as directories. It just seems to move the
incomplete flag from the directory to all of its childen.

>> +
>> +   ### this does not allow a change of depth
>> +
>> +   ### we do not update a file's TRANSLATED_SIZE here. at some future point,
>> +   ### when the file is installed, then a TRANSLATED_SIZE will be set.
>> +*/
>> +svn_error_t *
>> +svn_wc__db_global_update(svn_wc__db_t *db,
>> +                         const char *local_abspath,
>> +                         const char *new_repos_relpath,
>> +                         svn_revnum_t new_revision,
>> +                         const apr_hash_t *new_props,
>> +                         svn_revnum_t new_changed_rev,
>> +                         apr_time_t new_changed_date,
>> +                         const char *new_changed_author,
>> +                         const apr_array_header_t *new_children,
>> +                         const svn_checksum_t *new_checksum,
>> +                         const char *new_target,
>> +                         const svn_skel_t *conflict,
>> +                         const svn_skel_t *work_items,
>> +                         apr_pool_t *scratch_pool);
>> +
>> +
>
> Please provide suggestions and comments.
>
> The idea here is to perform a complete update of BASE_NODE and
> ACTUAL_NODE during an 'svn update' operation for a given node.
>
> Note: there *may* be occasions where we must also update WORKING_NODE.
> One particular example is an add/add conflict where the local-add
> matches the incoming-add. We want to remove the local-add in this
> case. For this particular case, Bert suggested that we handle this
> after the update() call as part of an automatic conflict resolution.
>
> Another example would be converting a presence=not-present (deletion
> of a child of a copied/moved-here tree) into a presence=base-deleted
> (the child is now part of BASE, so we mark that for deletion).

How does that occur? The parent is copied, the child is not-present.
If the child is going to become base-deleted the update must first
convert the copied parent into a normal base. Is that a tree conflict
that has been automatically resolved? And then the update does
something that converts not-present into base-deleted. I'm not sure
what that would be.

> Note that preparation of the CONFLICT parameter assumes that the
> existing database contents will not change during that prep time.
> Thus, we need to rely on the administrative wc lock during that
> period. The alternative would be flowing all the incoming data to
> wc_db and let it figure out everything (and bulking up wc_db even
> more(!)).
>
> Are there other approaches that we could take to perform this kind of
> change atomically?
>
> Cheers,
> -g
>

-- 
Philip
Received on 2010-03-30 12:18:26 CEST

This is an archived mail posted to the Subversion Dev mailing list.