You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philipp Marek <ph...@emerion.com> on 2009/02/16 07:40:59 UTC
Q about the delta editor interface
Hello everybody,
I just stumbled on the delta editors' interface definition (about
add_directory):
/** We are going to add a new subdirectory named @a path. We will use
* the value this callback stores in @a *child_baton as the
* @a parent_baton for further changes in the new subdirectory.
...
That's means (IMO) that the hierarchy gets described by the *baton* hierarchy;
but a simple test shows that it's more the *paths* that define the way the
entries are coupled.
To clarify:
I wrote a recursive function that gives the new baton to the subsequent calls,
and that uses "dir-a", "dir-b", "dir-c" etc. as path parameter.
This shows that these directories get created in the commit base directory,
and not nested like the batons suggest.
Now I know that it works by using the full paths, and that the full paths are
a bit easier to use for the libraries (because they don't have to build the
whole paths from the individual levels) - but it's a little bit nagging at me
(and it makes it much harder to implement a feature I'm currently at).
So, again - there's no hope to change that (because there are too many
consumers of this API, and revving it just because of that doesn't seem worth
the effort) - but is it only me that feels a bit uneasy? Any opinions?
Regards,
Phil
Re: Q about the delta editor interface
Posted by Greg Stein <gs...@gmail.com>.
On a separate note, I intend to rev the delta interface during 1.7
development. Not entirely sure what it will end up looking like, but
I'm hoping to make it more flexible, and much clearer.
Cheers,
-g
On Mon, Feb 16, 2009 at 08:40, Philipp Marek <ph...@emerion.com> wrote:
> Hello everybody,
>
> I just stumbled on the delta editors' interface definition (about
> add_directory):
> /** We are going to add a new subdirectory named @a path. We will use
> * the value this callback stores in @a *child_baton as the
> * @a parent_baton for further changes in the new subdirectory.
> ...
>
> That's means (IMO) that the hierarchy gets described by the *baton* hierarchy;
> but a simple test shows that it's more the *paths* that define the way the
> entries are coupled.
>
> To clarify:
> I wrote a recursive function that gives the new baton to the subsequent calls,
> and that uses "dir-a", "dir-b", "dir-c" etc. as path parameter.
> This shows that these directories get created in the commit base directory,
> and not nested like the batons suggest.
>
>
> Now I know that it works by using the full paths, and that the full paths are
> a bit easier to use for the libraries (because they don't have to build the
> whole paths from the individual levels) - but it's a little bit nagging at me
> (and it makes it much harder to implement a feature I'm currently at).
>
> So, again - there's no hope to change that (because there are too many
> consumers of this API, and revving it just because of that doesn't seem worth
> the effort) - but is it only me that feels a bit uneasy? Any opinions?
>
>
> Regards,
>
> Phil
>
>
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1169888
Re: Q about the delta editor interface
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Feb 16, 2009 at 10:55, Stephen Butler <sb...@elego.de> wrote:
> Quoting Philipp Marek <ph...@emerion.com>:
>
>> On Montag, 16. Februar 2009, Stephen Butler wrote:
>>>
>>> did you try calling open_directory(dir-a,...) after
>>> add_directory(dir-a,...)?
>>
>> No, I didn't .... aren't these exclusive?
>
> The two functions are independent, but not exclusive.
What? Of course they are.
You do:
open_directory(&baton, ...)
do_child_stuff(baton)
close_directory(baton)
or:
add_directory(&baton, ...)
do_child_stuff(baton)
close_directory(baton)
(arguments not exact; just for illustrative reasons)
You use one or the other. They are *not* used together. Each returns a
baton to use for child operations, and that baton should eventually be
passed to close_directory.
> add_directory() simply creates a directory. Before adding children
> or setting properties, call open_directory().
No. add_directory() creates and opens the directory. You do not call
open_directory() *unless* you first call close_directory() on the
baton returned by the open_directory.
>> What should I do with the baton acquired from add_directory()?
>
> Pass it as the child_baton to open_directory(same_path,...), as the
What?! child_baton is an OUT parameter. You can't pass it to open_directory().
> dir_baton to change_dir_prop(), and as the parent_baton to functions
> involving the dir's children.
>
> (Disclaimer: I've written a fair bit of delta-editor consumer code,
> but not driver code.)
Well... we're talking about how the driver calls these things.
>> Wouldn't the duplicate close_directory() (on two batons) make problems?
Yes, it would. Don't do that.
Cheers,
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1169886
Re: Q about the delta editor interface
Posted by Stephen Butler <sb...@elego.de>.
Quoting Philipp Marek <ph...@emerion.com>:
> On Montag, 16. Februar 2009, Stephen Butler wrote:
>> did you try calling open_directory(dir-a,...) after
>> add_directory(dir-a,...)?
> No, I didn't .... aren't these exclusive?
The two functions are independent, but not exclusive.
add_directory() simply creates a directory. Before adding children
or setting properties, call open_directory().
> What should I do with the baton acquired from add_directory()?
Pass it as the child_baton to open_directory(same_path,...), as the
dir_baton to change_dir_prop(), and as the parent_baton to functions
involving the dir's children.
(Disclaimer: I've written a fair bit of delta-editor consumer code,
but not driver code.)
> Wouldn't the duplicate close_directory() (on two batons) make problems?
Since there's only one baton per directory, call close_directory()
just once.
HTH,
Steve
--
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
Re: Q about the delta editor interface
Posted by Philipp Marek <ph...@emerion.com>.
On Montag, 16. Februar 2009, Stephen Butler wrote:
> did you try calling open_directory(dir-a,...) after
> add_directory(dir-a,...)?
No, I didn't .... aren't these exclusive?
What should I do with the baton acquired from add_directory()?
Wouldn't the duplicate close_directory() (on two batons) make problems?
Regards,
Phil
Re: Q about the delta editor interface
Posted by Stephen Butler <sb...@elego.de>.
Quoting Philipp Marek <ph...@emerion.com>:
> Hello everybody,
>
> I just stumbled on the delta editors' interface definition (about
> add_directory):
> /** We are going to add a new subdirectory named @a path. We will use
> * the value this callback stores in @a *child_baton as the
> * @a parent_baton for further changes in the new subdirectory.
> ...
>
> That's means (IMO) that the hierarchy gets described by the *baton*
> hierarchy;
> but a simple test shows that it's more the *paths* that define the way the
> entries are coupled.
>
> To clarify:
> I wrote a recursive function that gives the new baton to the
> subsequent calls,
> and that uses "dir-a", "dir-b", "dir-c" etc. as path parameter.
> This shows that these directories get created in the commit base directory,
> and not nested like the batons suggest.
>
>
> Now I know that it works by using the full paths, and that the full paths are
> a bit easier to use for the libraries (because they don't have to build the
> whole paths from the individual levels) - but it's a little bit nagging at me
> (and it makes it much harder to implement a feature I'm currently at).
>
> So, again - there's no hope to change that (because there are too many
> consumers of this API, and revving it just because of that doesn't seem worth
> the effort) - but is it only me that feels a bit uneasy? Any opinions?
Hi Philipp,
did you try calling open_directory(dir-a,...) after add_directory(dir-a,...)?
Regards,
Steve
--
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194