> -----Original Message-----
> From: Julian Foad [mailto:julian.foad_at_wandisco.com]
> Sent: woensdag 24 februari 2010 15:24
> To: dev_at_subversion.apache.org
> Subject: Re: WC-NG presence 'incomplete'
>
> On Mon, 2010-02-22, I (Julian Foad) wrote:
> > Documenting WORKING.presence = 'incomplete'...
>
> [...]
> > My take on this is that we should keep the meanings of the columns
> > orthogonal as much as possible. At the DB schema level, there's no
> > reason why files, dirs and sym-links should not all have props and
> > should not all be able to be incomplete in the sense of not having
> their
> > props yet. The higher level code might want to avoid ever having
> > incomplete file, or props on a symlink, but that's doesn't reduce the
> > benefit of keeping the schema meanings orthogonal. And there's no
> reason
> > to have more than one way of representing 'props are unknown'.
> >
> > So let's specify:
> >
> > * presence = 'incomplete' just refers to children when this is a
> > directory. (It does not mean anything about properties.)
> >
> > * 'properties' is NULL if the properties of this node are not (yet)
> > known. ('properties' is an empty skel if there are no properties.)
> >
> > Good?
> [...]
>
> Bert and Greg responded on IRC:
>
> > <Bert> julianf: You can't leave the properties out of incomplete..
> The
> > problem is a cancel between open_dir() and close_dir() and between
> > that you can receive some of the property changes (and miss a few of
> > them). When you cancel before the dir_close() you register as
> > incomplete... and when you update again you tell the repository: "I'm
> > incomplete: send me all the children *AND* all the properties"
> >
> > <gstein> julianf: and when Bert used the word "property", he also
> > means "entry properties", which are things like changed_*
> >
> > <Bert> There is no: "Send me all the childrent AND NOT all the
> > properties". (This is editor v1.0 and we had that since far before
> > 1.0)
>
> Let me talk about the regular, versioned properties only, for a moment.
> (The same principles can apply to other properties.)
>
> It is possible to cancel an operation after some properties have been
> received down the wire and before all of them have been received. That
> doesn't mean we need to be able to represent any such state in the DB.
> We could keep it simpler by agreeing that we will only change the
> stored
> 'properties' column from NULL to a complete list of properties, and
> never attempt to store "some but not all of the properties".
The problem is:
An update of a directory is like:
* Update the information on the directory to set the revision of the directory to the update-to-rev and set the directory to incomplete.
Then this is written to entries/WC-NG/whatever.
(We certainly can't see the directory as complete without seeing any property changes
Then we update the children of the directory in a depth first fashion.
Then perhaps we get some properties and store these for later use.
And finally after all children are updated:
* We commit the property changes (check for conflicts, etc.) and mark the directory complete.
(The original incomplete before the update defines how we handle the property changes. If it was complete we apply changes. If it was not complete we see the new list of properties as the new base-properties and do a diff with the old version)
In that first step of the update we can't just say: We have all the properties. We simply don't have them yet..
And we can't say we are still completely at the old revision or canceling while updating the children break, or we redefine what being at some revision tells us.
Every change to this scheme (which I think we had implemented far, far before 1.0) requires a completely new editor and *a lot of* compatibility code.
Think: New clients with old repositories and new repositories with old clients. (We can't break before 2.0)
That new editor step is in planning for 1.8 or around that, but requiring that whole step now probably pushes the release of 1.7 into 2011 by my estimation. (Unless we just fix this one issue by adding an additional editor v1.1 with small fixes before the full v2 that we are planning for later).
Sending the incomplete (as defined by editor v1) to a repository tells the server to send all children and all properties instead of just the changes. Changing this requires a new editor and code to wrap the new editor around the old one and the old one around the new one.
(Doing this for some simple examples of multi level trees shows that we probably have to spool an entire update drive to some storage and then reapply it in a different order for v1<->v2 as planned.)
So, not something that is implemented in a matter of weeks.
And I don't think you make Subversion users happy by not streamingly applying updates if they happen to use a non >= 1.7 repository, while with 1.0-1.6 you see the individual changes coming in throughout an update.
>
> A separate question is whether we require "presence=incomplete" when
> the
> properties are incomplete. We could instead define
> "presence=incomplete"
> to mean the children are not all known to be there, and have encoded
> by
> "properties=NULL" and perhaps also other forms of incompleteness. If we
> do the latter, then an "is this dir incomplete in any way?" API will
> examine both the "presence" column and the "properties" column to
> answer
> the question.
Properties = NULL was already used for 'there are no properties', but I think we can safely redefine that.
But for the current incomplete behavior we really need the old set of base properties to diff against the new set of base properties received in order to 'complete' a directory if the update was canceled during a previous update.
Bert
>
> - Julian
>
>
> > We can fix this with a new editor (and a lot of compatibility code..
> > and slow IO around that).. Not with just a new working copy
> >
> > gstein: *nod* Those are handled via the same API. (And you even
> > receive the repository UUID via those properties if I remember
> > correctly)
> >
> > <gstein> right
>
Received on 2010-02-24 15:45:53 CET