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 <cmpil...@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
