On Thu, 11 Aug 2005, Paul Burba wrote:
> "Peter N. Lundblad" <firstname.lastname@example.org> wrote on 08/11/2005 02:20:09
> > I don't think you need to rev the client API. You can add fields to the
> > end of svn_wc_status2_t (that's even documented!).
> > This chage seems pretty straight forward to me. Just add the fields you
> > need, and catch the entryprops in change_file_prop and change_dir_prop
> > libsvn_wc/status.c. The URL field is a little tricky because of
> > entries. For entries that exist in the WC, it is readily available. For
> > added paths, there must be a nearest ancestor in the WC with an URL that
> > you can extend.
> In looking at this, I came to more or less the same conclusion, though
> undoubtedly it took me a *bit* longer to figure it out.
> I'm still unsure about the need to rev svn_wc_status2_t or not. Looking
> at r13791 (Rev the svn_wc_status_t structure to svn_wc_status2_t, so as
> not to break ABI) as a roadmap for adding to svn_wc_status_t, the
> implication is that I need to rev svn_wc_status2_t, svn_wc_dup_status2,
> svn_wc_status2, etc...but r13805 added the comment you alluded to above:
> * @note Fields may be added to the end of this structure in future
> * versions. Therefore, users shouldn't allocate structures of this
> * type, to preserve binary compatibility.
> Does this warning alone give the green light to add members to
> svn_wc_status2_t without revving it? The following thread on ABI breakage
> reveals no widespread consensus on this topic:
We've discussed something similar more recently:
My interpretation of this discussion in relationship to the issue at hand,
in conjunction with the documentation on that structure, indicates that you
(conceptually) have the green light, Paul.
With regard to the referenced mail thread, I chose not to add a field to the
end of the struct based on API considerations mentioned by Greg Hudson (which
I privately shared), rather than ABI compatibility concerns.
Received on Fri Aug 12 04:13:33 2005