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 certainly could have saved you some time by posting earlier. Sorry for
that. Hope you learned some things during your tour:-)
> 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.
>
The reason svn_wc_status_t was revved was that there was no such clause in
that documentation and there were public APIs consuimg such struct that
could have been allocated by the caller. If people allocate
svn_wc_status2_t structs themselves, then I wouldn't mind if someone sent
them naked to Antarctica. You can safely add fields to the end of this
struct.
Thanks,
//Peter
Received on Fri Aug 12 05:48:53 2005