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

Re: [Subclipse-dev] Enhancement needed in svn status -u

From: Daniel Rall <dlr_at_finemaltcoding.com>
Date: 2005-08-11 20:13:33 CEST

On Thu, 11 Aug 2005, Paul Burba wrote:

> "Peter N. Lundblad" <peter@famlundblad.se> wrote on 08/11/2005 02:20:09
> AM:
> > 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
> in
> > libsvn_wc/status.c. The URL field is a little tricky because of
> switched
> > 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:
> http://svn.haxx.se/dev/archive-2005-03/0929.shtml

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.

- Dan

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 11 20:14:00 2005

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.