Thanks for the additional background, Hyrum.
r1133417 moves and renames the struct to become both svn_wc__info2_t and
svn_client_info2_t. It's certainly a kind of duplication but it's also
the most straightforward solution, I think.
I added a 'dup' function for the public one; doing that is what first
made me aware of the cyclic dependency and the reason why it should be
changed. I haven't yet added a constructor.
- Julian
On Tue, 2011-06-07, Hyrum K Wright wrote:
> Oh, and if it hasn't already grown one yet, svn_info2_t needs a
> constructor. svn_wc_info_t doesn't, since it's always created by
> libsvn_wc.
>
> -Hyrum
>
> On Tue, Jun 7, 2011 at 2:12 PM, Hyrum K Wright <hyrum_at_hyrumwright.org> wrote:
> > As the original author of svn_info2_t, I'll share some thoughts which
> > might be of use.
> >
> > The struct was originally defined as svn_info_t in svn_client.h, but
> > with wc-ng, it needed a face lift. At the same time, I recognized the
> > fact that info can be obtained via a URL, which returned a subset of
> > that information obtained by querying a working copy path. That
> > insight led to the current implementation, where svn_info2_t is
> > defined in svn_types.h, with an opaque reference to svn_wc_info_t
> > which is defined in svn_wc.h. (Or at least, I think that's the
> > current state of affairs.)
> >
> > There is an email thread from when this was all happening in which
> > Greg and I debated whether or not svn_info2_t should be in svn_wc.h or
> > svn_client.h or svn_types.h. It basically boiled down to the fact
> > that: a) info on a URL is a subset of info on a WC; and b) a structure
> > which returns information solely coming from a URL shouldn't be
> > defined in svn_wc.h. (A client doesn't even need a working copy to
> > run 'svn info $URL'.)
> >
> > In the end, I'm for whatever is more maintainable, but let's not try
> > to over-engineer things.
> >
> > -Hyrum
> >
Received on 2011-06-08 17:09:45 CEST