Previously, we returned a tuple containing counts. The result of an
update is kind of complex and the use of tuples with nameless fields
made the code a bit harder to read and constrained future expansion
of the return value.
Let's invent an attrs-defined class for representing the result of
an update operation.
We provide getitem and len implementations for backwards
compatibility as a container type to minimize code churn.
In (at least) Python 2, the % operator seems to insist on using
tuples. So we had to update a consumer using the % operator.
.. api::
merge.update() and merge.applyupdates() now return a class with named attributes instead of a tuple. Switch consumers to access elements by name instead of by offset.
mpm made me use a tuple with slots for scmutil.status. Any idea when that's better? I think it was something about performance, but we don't care about that here.