On Mon, Aug 18, 2014 at 06:40:16PM +0200, Bert Huijben wrote: > Can you document how property conflicts are stored in this array. For the > previous versions we have multiple ways to encode these. > > An info call is pretty performance critical for many gui clients so it > shouldn't start creating temp files for every property conflict it notes, or > many different db calls for data that not everybody needs. > > Returning everything from generic APIs, potentially including expensive to > obtain data is not the recommended way to do things. It is better to obtain > the expensive parts on demand via different functions. > > The best conflict descriptor might be a simple reference that can just be > used by a different function set. We don't want to recreate the problems of > svn_wc_entry_t. > > Bert
You make a good point but this goes beyond what svn_wc_conflict_description3_t does. It's just a better version of svn_wc_conflict_description2_t without some of the quirks, such as storing the prop reject file path in the wrong field. And it has some fields renamed for clarity. It's *not* a better API. Going forward, I agree a much better API to describe conflicts will be needed. But we're not quite there yet, I think.
