You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@wandisco.com> on 2012/04/12 17:19:40 UTC
Editorr v2 svn_editor_alter_directory needs list of children
I think alter_directory needs a list of children as well as the new
properties. Consider an update from
relpath revision props
3
A 3 p=v
A/X 3
to
relpath revision props
4
A 4 p=vvv
A/X 4
A/Y 4
The v2 editor drive will call alter_directory to change the properties
on A and add_directory to add the child A/Y.
The alter_directory call cannot change the properties of A without
changing the revision, but it cannot simply change the revision of A if
A/Y has not yet been added. The best solution seems to be that
alter_directory should have a list of the children, just like
add_directory, then it can add any missing children as incomplete,
change the properties and update the revision.
An alternative might be marking A incomplete, like a v1 drive. I don't
like that, I would prefer it if v2 could reserve incomplete for nodes
that are just names and have no content.
Another alternative might be imposing a drive order restriction, only
allow alter_directory after all children have been added. I don't think
that is right either, v2 tries to avoid depth order restrictions.
If we consider a node's "content" to consist of text+props for files and
children+props for directories then we see that the current alter_file
already supplies all the content for file nodes while the current
alter_directory only supplies part of the content for directory nodes.
Adding children to alter_directory removes that difference.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Editorr v2 svn_editor_alter_directory needs list of children
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Apr 12, 2012 at 12:06 PM, Julian Foad
<ju...@btopenworld.com> wrote:
> Philip Martin wrote:
>
>> I think alter_directory needs a list of children as well as the new
>> properties.
>
> I agree. I already felt that was needed for API symmetry (or else the add_directory() should *not* take the list of children). Now your use case below adds a practical reason.
Fixed in r1334244.
>...
>> An alternative might be marking A incomplete, like a v1 drive. I don't
>> like that, I would prefer it if v2 could reserve incomplete for nodes
>> that are just names and have no content.
Right. That was always the design plan.
> An important point here is that, by knowing the list of children, the semantics of the WC "incomplete" status can be greatly simplified. We will only ever need to make new children "incomplete", never the directory itself. Now the "incomplete" status will only need to mean, "We know there is a node with this name; we know nothing else about it". It will no longer ever need to mean "This directory has some children which are completely (or partially?) fleshed out, and/or perhaps some that we don't know anything about yet".
Sure. That's why the wc_db interface and why the Ev2 add_directory API
requires the set of children up front. I just missed doing the same
for alter_directory. We're good now!
As a concrete example/improvement: during a checkout/update, a new
directory is "done" immediately. If the update stops, and is
restarted: you don't have to ask about the directory and its set of
children. *Just* the subset of children which are still incomplete.
Cheers,
-g
Re: Editorr v2 svn_editor_alter_directory needs list of children
Posted by Julian Foad <ju...@btopenworld.com>.
Philip Martin wrote:
> I think alter_directory needs a list of children as well as the new
> properties.
I agree. I already felt that was needed for API symmetry (or else the add_directory() should *not* take the list of children). Now your use case below adds a practical reason.
> Consider an update from
>
> relpath revision props
> 3
> A 3 p=v
> A/X 3
>
> to
>
> relpath revision props
> 4
> A 4 p=vvv
> A/X 4
> A/Y 4
>
> The v2 editor drive will call alter_directory to change the properties
> on A and add_directory to add the child A/Y.
>
> The alter_directory call cannot change the properties of A without
> changing the revision, but it cannot simply change the revision of A if
> A/Y has not yet been added. The best solution seems to be that
> alter_directory should have a list of the children, just like
> add_directory, then it can add any missing children as incomplete,
> change the properties and update the revision.
>
> An alternative might be marking A incomplete, like a v1 drive. I don't
> like that, I would prefer it if v2 could reserve incomplete for nodes
> that are just names and have no content.
An important point here is that, by knowing the list of children, the semantics of the WC "incomplete" status can be greatly simplified. We will only ever need to make new children "incomplete", never the directory itself. Now the "incomplete" status will only need to mean, "We know there is a node with this name; we know nothing else about it". It will no longer ever need to mean "This directory has some children which are completely (or partially?) fleshed out, and/or perhaps some that we don't know anything about yet".
That simplification in itself sounds like a very good reason to go this way.
- Julian
> Another alternative might be imposing a drive order restriction, only
> allow alter_directory after all children have been added. I don't think
> that is right either, v2 tries to avoid depth order restrictions.
>
> If we consider a node's "content" to consist of text+props for
> files and
> children+props for directories then we see that the current alter_file
> already supplies all the content for file nodes while the current
> alter_directory only supplies part of the content for directory nodes.
> Adding children to alter_directory removes that difference.
>
> --
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com
>