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.
Received on 2014-08-18 18:52:46 CEST