[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] support printing changed properties in svnlook

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Tue, 14 Dec 2010 10:05:35 +0200

Erik Johansson wrote on Mon, Dec 13, 2010 at 22:27:04 +0100:
> On Fri, Dec 10, 2010 at 14:29, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> > Could you untangle this mess around driving the editor?  (I might be
> > able to look into this later, but not right now)
>
> See attempt in other thread.
>

Saw the thread, marked it for attention, will get to it hopefully soon.

> >> >> +} svn_repos_node_prop_t;
> >> >
> >> > I'm afraid you can't extend this struct due to binary compatibility
> >> > considerations (an application built against 1.6 but running against 1.7
> >> > will create too short a struct).
> >>
> >> This was actually one of my concerns as well. I will try to come up
> >> with another way of doing it.
>
> I've been thinking some more about this:
> - svn_repos_node_t is never used as an in parameter, so there
> shouldn't be any need for applications to create one.
> - If an application creates a svn_repos_node_t, the only use for it
> would be internal to the application in which case it will use its
> version of the struct even if we change it.
> - If we add the new field to the end of the struct there should be no
> problems for applications built with an old version of the struct;
> they will simply not be able to access the new field.
>

So, there would be TWO svn_repos_node_t structs in an
appliaction:

* Those provided by the callbacks
  (1.7 style, but application doesn't read the new fields, and we never
  read them after the callback had had an opportunity to touch them)

* Those constructed by the application
  (svn libraries should never see them so we Don't Care)

> What do you think?
>

Technically, it's probably going to work. (at least as long as we don't
add a function that takes an svn_repos_node_t parameter, etc)

But it's a grey area, and having special cases both complicates
everyone's lives and weakens our API compatibility guarantees.

Call me conservative, but I don't like this option; I would rather not
get into this corner when we could just revv the struct, add
a constructor and duplicator for the new struct, and solve the problem
once and for all. (We have precedent for struct types being defined ---
not just declared --- in the public headers, along with a comment "Don't
allocate it by yourself; use foo_create() to create it.")

> // Erik
>
Received on 2010-12-14 09:08:18 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.