We already fetch the properties, but we just do an isnull check on those columns, so it is just a case of adding yet another optional output argument. (I wouldn’t remove the old ones as parsing properties is not always cheap. I know some specific users store kbytes of binary data in there and our mergeinfo is not small either)
I’m not sure if this is the way to go though. Maybe we should store some symlink and eol-translation info outside the properties and avoid using properties in far more cases. But we can always do this at another point in time. Bert *From:* Julian Foad <julianf...@btopenworld.com> *Sent:* December 4, 2012 11:41 PM *To:* Subversion Development <dev@subversion.apache.org> *CC:* Bert Huijben <b...@qqmail.nl> *Subject:* Add properties output param to svn_wc__db_*_get_info()? Bert and others: Would it be OK (performance-wise) to add optional 'properties' outputs to the svn_wc__db_base_get_info() svn_wc__db_depth_get_info() svn_wc__db_read_info() APIs, instead of the separate and irregular APIs we currently have for specifically requesting the props? The point is to regularize the APIs. I want to know if the act of including the props field in the main SQL request would be cause for concern. Alternatively we can just issue a second SQL stmt for the props, but within the same func, if that seems better. - Julian -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
