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