On 08/13/2010 01:04 PM, Bert Huijben wrote:
>
> svn_log_changed_path2_t is defined as a structure starting with the exact
> same definition as svn_log_changed_path_t. So any svn_log_changed_path2_t
> instance can be seen as a svn_log_changed_path_t, but you miss some
> fields that way.
>
> The problem is that we never created create and duplicate functions for
> svn_log_changed_path_t, so it was impossible to add new fields. So we
> revved the structure (and the hash containing it) to pass the new data
> instead. But you can safely pass the new value as the old value, but not
> the other way around. (The only other option to provide more per path
> data was to rev every log function inside the fs, ra and client layer)
>
> As we never consume these structures, we can define (like that doctag
> says), that you always get the same hash pointer if the second hash
> pointer is available. (We just create the new hash and that value happens
> to be valid as the old hash)
>
> We have had a similar construct in svn_io_* for years, where we passed a
> svn_node_kind* as value from a hash, then some struct and then later a
> larger struct.. but you always get the same pointers, because the layout
> matches.
Thank you! Any chance you'd be willing to distill that explanation into
something suitable for inclusion in that header file -- or tweak what's
there -- in case others later wonder the same thing?
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2010-08-13 19:13:54 CEST