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 <hy...@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 > >
