[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: Greg Stein <gstein_at_gmail.com>
Date: Tue, 30 Mar 2010 12:13:47 -0400

On Tue, Mar 30, 2010 at 06:17, Philip Martin <philip.martin_at_wandisco.com> wrote:
> 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
>>> +   ### 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

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


Received on 2010-03-30 18:14:15 CEST

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