On Sun, Sep 11, 2011 at 03:56:39PM +0300, Daniel Shahaf wrote:
> I floated on IRC the idea of having the output not try filter out
> inoperative revisions.
That would not completey fix the problem.
In the case we're looking at there is one huge gap in the range of
revisions already merged. So, yes, the output would be short if we
collapsed inoperative revisions -- we'd just print a single range.
However, what if I want to reintegrate a long-lived branch in which
every other revision was a cherry-pick merge from trunk?
In this case, the missing revisions are N, N+2, N+4, ...
which cannot be combined into a single range. This is a contrived case,
of course. But I'd prefer a solution that cannot cause such problems
under any circumstances.
We shouldn't try to keep a list of unknown and potentially massive
size in memory. So putting this list into an error message is wrong.
At the very least, we should pass off ranges to a client-provided callback
as we receive them from the server. Then the client can print each range
and the range can be freed immediately before the server sends the next one.
But, again, I don't see how printing a precise, but massive, list of
missing revisions helps users. The time spent downloading and displaying
all this information could be better spent if we told users "there are
one or more missing ranges, please run a sync merge from trunk first,
and try again."
Received on 2011-09-12 22:06:18 CEST