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?
> +
> + ### 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).
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
Received on 2010-03-30 02:04:41 CEST