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 <philipp.marek_at_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
Received on 2009-02-16 11:31:05 CET