On Wed, 2010-11-10, Greg Stein wrote: > It is used *once* ?! > > Bleh. Then I'd ask why we even have the type, especially why does it > exist in svn_types.h.
I wondered the same. The answer appears to be that 'svn_log_changed_path2_t' (which was added to svn_types.h in 1.6) has now been extended with two new fields, 'text_modified' and 'props_modified', which are only valid in certain cases, as part of r877688: > r877688 | rhuijben | 2009-05-06 17:02:16 +0100 (Wed, 06 May 2009) | 46 lines > > Provide information on whether the text and/or properties were changed for > each changed path in a revision. This patch makes the information available > to api users and the svn log -v --xml output. > > * subversion/include/svn_types.h > (svn_tristate_t): New type. > (svn_tristate_to_word, svn_tristate_from_word): New function. > (svn_log_changed_path2_t): Add two new fields. > > * subversion/libsvn_ra_neon/log.c > (log_start_element): Parse text-mods and props-mods attributes. > > * subversion/libsvn_ra_serf/log.c > (read_changed_path_attributes): New function to parse node kind and > modification types. > (start_log): Move node kind parsing to read_changed_path_attributes. > > * subversion/libsvn_ra_svn/client.c > (optbool_to_tristate): New function. > (ra_svn_log): Add parsing of two new optional booleans. > > * subversion/libsvn_ra_svn/protocol > (changed-path-entry): Fix optional parts for node kind and add text-mods > and prop-mods. > > * subversion/libsvn_repos/log.c > (detect_changed): Copy text and property modified values from fs api. > > * subversion/libsvn_subr/kitchensink.c > (svn_tristate_to_word, svn_tristate_from_word): New function. > > * subversion/mod_dav_svn/reports/log.c > (log_receiver): Move common attribute generation code to a single place and > provide text-mods and prop-mods attributes. > > * subversion/svn/log-cmd.c > (log_entry_receiver_xml): Add text-mods and prop-mods attributes. > > * subversion/svn/schema/log.rnc > (attlist.path): Declare text-mods and prop-mods attributes. > > * subversion/svnserve/serve.c > (log_receiver): Provide two extra booleans, removing optional definition > from the node-kind as we always provide this. (Writing optional booleans > is not supported by the svn tuple code). The question is: would we prefer to represent the data another way? For example, we could perhaps make them booleans and say that if both are false when action = 'M', that means the specific data is NOT available, and if either or both is true then that means it IS available. Stefan2 has gone on to use the tristate type for two more purposes in his performance branch, but I'm not sure that we've yet demonstrated it's worth making it a (svn-)global public type. - Julian
