Are public consumers intended to read the information from
svn_wc__info2_t? If so, making it Subversion-private hardly seems
On Wed, Jun 8, 2011 at 10:09 AM, Julian Foad <julian.foad_at_wandisco.com> wrote:
> 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
>> 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 18:55:32 CEST