Re: atomic update

[Philip Martin <ph...@wandisco.com>]

Greg Stein <gs...@gmail.com> writes:

> On Mon, Mar 29, 2010 at 19:40,  <gs...@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

Re: atomic update

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

On Tue, Mar 30, 2010 at 06:17, Philip Martin <ph...@wandisco.com> wrote:
> Greg Stein <gs...@gmail.com> writes:
>> On Mon, Mar 29, 2010 at 19:40,  <gs...@apache.org> wrote:
>>>...
>>> +++ subversion/trunk/subversion/libsvn_wc/wc_db.h Mon Mar 29 23:40:55 2010
>...
>>> +   ### 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) ?
>...
> What is NEW_TARGET?

New symlink 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.

Yes. By moving the incomplete status to the children, you can
add/update a directory atomically. You know which children are needed
if an interruption occurs.

In wc-1, the directory is marked incomplete until all of the children
arrive. An interruption meant that you have to fetch the directory and
all its children *again* (rather than just each remaining incomplete
child).

>...
>> 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.

The scenario is that the parent-copied node is somehow resolved into
"equal to what we just got from the update", so the copy goes away.
The deleted child is now actually a deleted base.

Could that actually happen? Beats me :-P ... just trying to blue-sky
some examples.

As I said: I hope that we never have to touch WORKING. That we can
simply modify BASE, and possibly insert some conflict data into
ACTUAL.

>...

Cheers,
-g