[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Confusing svn_log_entry_t docstrings.

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Fri, 13 Aug 2010 13:13:16 -0400

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.