Greg Stein <[email protected]> writes: > On Mon, Mar 29, 2010 at 19:40, <[email protected]> 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
